Transcript Class One - Lyle School of Engineering

 Welcome to CSE 5348/7348 "Inter and Intra Networking
Protocols".
 Primary Text: Richard Stevens "Unix Network
Programming", Volume 1
 ISBN 0-13-490012-X
 Reference Text: Richard Stevens "Unix Network
Programming", Vol 2.
 ISBN 0-13-081081-9
 Instructor: Mr. Russo
 Rules of the road:
 Basic conversational courtesy is a mandate.
 Punctuality is a virtue.
 Grading
 Objective of the grading process.
• Historical data

3 tests: 2 midterms, Final
• Cheating is NOT TOLERATED in any form.

Grade is calculated based on:
• 70% from tests scores
• 15% on Class Participation including presentation
• 15% on Homework assignments (TA and Instructor Graded).
 Communication:
 Office Hours: Friday from 11:00 AM to 2:00 PM in the
Adjuncts office.
• Lab sessions on Thursday evenings as needed.



[email protected]
214-549-0960 (email first unless emergency)
www.seas.smu.edu/~drusso
•
•
•
•
All class notes posted at this site.
All messages posted at this site.
Reference daily.
Test results will be made available via server side JSP at
www.Trisential.com (more information later).
 "To not learn from History is to doom oneself to repeat
it".
 History of Computer Communication.
 In the beginning, when all was null and void, there
was SNA (System Network Architecture) and 3270.
• IBM Proprietary solution circa mid '70's.



In addition there were other solutions based on XNS
(Xerox Network System) such as Novell Netware and
Banyan VINES.
DEC had DECnet and LAT (Local Area Transport).
All of these protocols could run over 802.3, 802.5 and
FDDI.
 The problem was that ALL of these protocols were
PROPRIETARY (vendor dependent), i.e. marketing ploys
employed to sell more equipment not to interconnect
heterogeneous computer systems.
 General Rule: Open architectures thrive, closed
architectures die.
XNS from Vendor A might not work with XNS from
Vendor B.
X.25 was a public WAN protocol but it was slow and not
all suppliers implemented 100% of the protocol so
interoperability problems were manifest.
 Many people don't realize that there is more than a
metaphor which connects the"Information
Superhighway" with the Interstate Highway System.
 The Interstate Highway System was not built so you
could jump in your SUV and take the family on
vacation.
 The Roman road system was built to move Legions
around the Mediterranean Basin.
 In 1957, while responding to the threat of the Soviets in
general and the success of Sputnik in particular,
President Dwight Eisenhower created both the Interstate
Highway System and the Advanced Research Projects
Agency, or ARPA.
 ARPA - DoD directive 5105.15 establishing the Advanced
Research Projects Agency (ARPA) was signed on
February 7, 1958. The directive gave ARPA the
responsibility "for the direction or performance of such
advanced projects in the field of research and
development as the Secretary of Defense shall, from time
to time, designate by individual project or by category."


Sputnik effect:
One of the ARPA projects was to develop a
communications capability that could survive
the adverse effects of nuclear war.
 Could the Internet survive a nuclear war?
 The biggest problem is the EMP (Electro Magnetic Pulse)
pulse. The first missiles to fly would explode at highaltitude. These explosions would result in an
unprecedented EMP pulse that would cripple virtually
90% (Military estimates put this at closer to 95% of more)
of all electronics in the U.S. Almost anything with a
microchip in it would be gone.
 Nikita Kruschev : "In a nuclear war-the living will envy
the dead..."
 The point is that ARPA wouldn't have happened, if what
used to be the Soviet Union hadn't shaken a complacent
U.S. awake with a tin can in the sky, Sputnik.
 Wars do wonders for the advancement of technology,
and the Cold War was certainly no exception. The way to
get a technology advanced is to gather a lot of really
smart people under one roof and get them to
concentrate on a single project.
 The top brass wouldn't be able to get in touch and carry
on. Thus the packets bouncing from node to node, each
of those nodes able to send, receive and pass on data
with the same authority as any other. It was anarchy that
worked, and on a technical level, it still does, obviously.
 1969: The first LOGs: UCLA -- Stanford
 According toVinton Cerf:
...the UCLA people proposed to DARPA to organize and
run a Network Measurement Center for the ARPANET
project...

 Around Labor Day in 1969, BBN delivered an Interface
Message Processor (IMP) to UCLA that was based on a
Honeywell DDP 516, and when they turned it on, it just
started running. It was hooked by 50 Kbps circuits to
two other sites (SRI and UCSB) in the four-node
network: UCLA, Stanford Research Institute (SRI), UC
Santa Barbara (UCSB), and the University of Utah in Salt
Lake City.
 In late 1971, Larry Roberts at DARPA decided that people
needed serious motivation to get things going. In
October 1972 there was to be an International
Conference on Computer Communications, so Larry
asked Bob Kahn at BBN to organize a public
demonstration of the ARPANET.
 It took Bob about a year to get everybody far enough
along to demonstrate a bunch of applications on the
ARPANET. The idea was that we would install a packet
switch and a Terminal Interface Processor or TIP in the
basement of the Washington Hilton Hotel, and actually
let the public come in and use the ARPANET, running
applications all over the U.S ....
 The demo was a roaring success, much to the surprise
of the people at AT&T who were skeptical about whether
it would work.
 TCP/IP (Transmission Control Protocol / Internet
Protocol) originated when DARPA was asked to develop
a solution that allowed different computers to
communicate with one another as if they were identical.
 This was particularly difficult in that all computer
architectures in that era were highly guarded secrets
(nobody would disclose how anything worked somewhat like microsoft).
 The TCP/IP architectural approach therefore was based
on the concept of TCP/IP running as an application.
 This allowed the components to function without
knowing the details of the foundation OS.
 To facilitate this development DARPA provided grants to
UCLA, UCSB and Stanford (SRI).
 Parallel with the development of TCP/IP many
companies were introducing computers, which could
communicate using Ethernet (Xerox implementation of
802.3).
 Several networks were developed employing TCP/IP
 CSNET
 BITNET
 UUCP
 USENET
 All of this development was undertaken by professors
and students.
 The development of the Internet was NOT driven by
companies but by the United States Government and
Universities.
 The NSF built the NSF network hooking five super
computers together.
 A provision of attaching to the NSF net was that any
attaching network had to be opened to the use of the
NSFnet (1986)
 connected using 56k bps lines (upgraded to T1 in '88)
As word spread other networks began to attach to the
NSFnet thereby increasing the overall network
capability.
 Word spread exponentially about the NSFnet.
 So many requests for connection were received that NSF
decided it could no longer support the NSFnet.
 The functional responsibilities of running the NSFnet
was passed to several companies.
 These companies setup Network Access Points (NAP)
located throughout the United States. These NAP
represented points at which companies with their own
backbones could connect to the NSFnet.
 The NSFnet name was dropped and replaced by the
phrase "Internet" (from IP).
 The concept of 'peering' was introduced. The Internet is
DEMOCRATIC (therefore it works).
 Peering meant that if you wanted to allow access to the
Internet by your backbone all other providers could use
your backbone for their traffic.
 Of course this was a shocking concept to the capitalist
business approach: Why should I allow another provider
to use my backbone for their traffic?
 Because NSF stated this and the movement to restrict
access was tabled.
 Example of a real backbone
 NAPs are the highest point in the Internet.
 Many private backbones are built and connected at
NAPs.
 No company 'owns' the Internet or any part of it.
 Everyone associated with the Internet has to abide by
the rules associated with it.
 Example: Network Solutions has the right to control
the domain Name registration. It does NOT own this
right and must abide by the rules of the Internet
Assigned Numbers Authority.
 Individual backbone providers then interconnect
multiple connections known as Points-Of-Presence
(POPs). This is where the user or business connects.
The Governing Bodies of the Internet
 How is the Internet managed?
 To some the fact that the Internet functions at all is
nothing short of a miracle - thousands of companies
must work in complete cooperation.
 Millions of people all following one set of rules;
particularly unlikely in a field as dedicated to anarchy as
software development.
 The Internet is democratic and participatory (as is any
effective democracy).
 As the Internet grew various boards and committees
were formed to manage the activities.
 The IAB (Internet Architecture Board) governs TCP/IP.
 ICCB (Internet Configuration Control Board) was setup
to help manage the activities of the Internet.
 Later the ICCB was disbanded and in its place a
number of Task Forces were founded.
 The IAB consists of the chairs of the various task
forces.
 IETF (Internet Engineering Task Force) combined
working groups into Areas and designated Area
Directors.
 An IESG (Internet Engineering Steering Group) was
formed from the various Area Directors.
 Requests For Comments (RFC).
 A community based method for making changes to the
Internet rules and protocols.
 Anybody may submit an RFC.
 RFC 1543 contains the details on how to submit an RFC.
 RFC's 1812, 1122 and 1123 are the most significant
RFC's for the TCP/IP suite.
 RFCs can be found at http://www.cis.ohiostate.edu/cs/Services/rfc/rfc.html
 ASSIGNMENT: Graduate Students read RFC 1812 in
detail and be ready to discuss in class.
 Undergrads: read sections 2 and 3 of RFC 1812.
Why Study the RFCs?
 Request for Comments technically define a
protocol for the Internet and are informational,
or even humorous.
 First RFC written by Steve
Crocker.
 Sent via “snail mail” until FTP came along
 An RFC can be submitted by anyone.
 Does not automatically become an RFC
 First enters as an RFC draft with no number
associated
 Must follow the instructions for authors
detailed in RFC 1543
Submitting an RFC
 Anyone can submit an RFC according to
RFC 1543.
 A major source for RFCs is the Internet Engineering
Task Force (IETF) which now has over 75 working
groups
 The primary RFC, including all diagrams,
must be written in 7-bit ASCII text.
 The secondary publication may be in
postscript.
 Once issued, RFCs do not change.
 Updated by new RFCs
 RFCs can be obsoleted but their
numbers are never used again
RFC Updates
 To join or quit the IETF-Announce list, send
an email to:
 [email protected]
 To join or quit the RFC-DIST list, send an
email to:
 [email protected]
RFC Format
Running header
Network Working Group
Author name (first
initial and last name)
Request for Comment < place number here>
Author Organization
Obsoletes/Updates: <place RFC number here>
Submission Date
Category:
Title
Status of this memo
Abstract
Table of Contents
Running Footer
RFC Format (continued)
Other RFC Format Requirements
 Introduction.

Each RFC should have an Introduction section that (among
other things) explains the motivation for the RFC and (if
appropriate) describes the applicability of the protocol
described
 RFC text.

The body of the RFC
 Discussion.

The purpose of this RFC is to focus discussion on particular
problems in the Internet and possible solutions
 Acknowledgments.

This is where the author may place individual acknowledgment
of others
Other RFC Format Requirements (continued)
 References.

Nearly all RFCs contain citations to other documents, and
these are listed in a References section near the end of the
RFC. There are many styles for references, and the RFCs have
one of their own.
 Security considerations.

All RFCs must contain a section near the end of the document
that discusses the security considerations of the protocol or
procedures that are the main topic of the RFC.
 Author’s address.

Each RFC must have at the very end a section giving the
author’s address, including the name and postal address, the
telephone number, a FAX number (optional), and the Internet
email address.
Requirements for RFCs
 MUST–The word or adjective “REQUIRED” means that the item is an absolute
requirement of this specification.
 MUST NOT–This phrase means the item is an absolute prohibition of this
specification.
 SHOULD–The word or the adjective “RECOMMENDED” means that there may
exist valid reason in particular circumstances to ignore this item, but the full
implications should be understood and the case carefully weighed before
choosing a different course.
 SHOULD NOT–This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is acceptable or even useful,
but the full implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
 MAY–This word or the adjective “OPTIONAL” means that this item is truly
optional. One vendor may choose to include the item because a particular
marketplace requires it or because it enhances the product, while another vendor
may omit the same item.
•TCP/IP and the ISO/OSI Model
Application
Presentation
Session
Transport
TELNET
FTP
SMTP
DNS
SNMP
DHCP
RIP
RTP
RTCP
Transmission
Control Protocol
User Datagram
Protocol
OSPF
ICMP
IGMP
Internet Protocol
Network
ARP
Datalink
Physical
Ethernet
Token Bus
Token Ring
FDDI
IGPs, EGPs, and Routing Protocols
 There is a difference between a routing protocol and a
routable protocol.
 A routing protocol is one that is used to propagate
route path information on a network
 A routable protocol is one that has the ability to be
routed as opposed to a nonroutable protocol such
as NetBIOS
 IGPs (Interior Gateway Protocol) are used as routing
protocols within
an AS (Autonomous Systems).
 EGPs (External Gateway Protocol) are used as routing
protocols between ASs.
Introduction to Routing Protocols
 Rooted in the early days of the ARPAnet.
 Historically tied to the Xerox XNS network operating
system
 IP is a routable protocol, it needs a routing protocol to
route between subnets.
 It is known as a distance vector protocol.
 It builds a table of known networks, which is distributed
to other routers.
 A hop is one router traversed.
Introduction to Routing Protocols (OSPF)
 OSPF is an IGP routing protocol.
 Operates differently than RIP.
 Used on small, medium, and large
networks.

Most beneficial on large, complex
networks
 It is a link-state protocol.

It maintains the knowledge of all links (interfaces) in the AS
 The link information is flooded to all other routers in the AS (or
area).

All routers receive the same link information
 All routers compute their own tables based
on the link information.
Other IP-Related Protocols
 ICMP (Internet Control Management Protocol) is an
extension of the IP protocol.
 IP is connectionless but connection oriented.
 Possible to have errors but they are not reported by IP
 ICMP allows for internet devices to transmit error or test
messages
 IGMP (Internet Group Management Protocol) is also an
extension of the IP protocol.
 Allows for multicast to operate on an internetwork
 Allows hosts to identify the groups they want to the router
 ARP provides the ability to translate between 48-bit
physical-layer addresses and 32-bit IP addresses.
Introduction to Transport Layer Protocols
 TCP provides for reliable data transfer using sequence numbers
and acknowledgments.
 UDP provides a simple connectionless transport layer to allow
applications access to the IP.
 ASSIGNMENT: ALL STUDENTS: Read Chapter 1 and 2 in Steven's
book Volume 1.
 ASSIGNMENT: Undergrads: Problem 2.3 and 2.6. Graduate
Students Problems 2.3, 2.4, 2.5 and 2.6.
 All assignments are due in the next class. No excuses allowed
except for
Death in family - certificate needed.
Sickness (Doctor's note)
Abduction by UFO (picture required)
Picture must be acompanied by
an artifact.
Data Encapsulation by Layer
Data
Application
TCP Segment
TCP
Datagram
IP
Packet
Data Link
Workstation
Frame
 TCP Header
 Source Port:

16 bits - The source port number.
 Destination Port:

16 bits - The destination port number.
 Sequence Number:

32 bits - The sequence number of the first data octet in
this segment (except when SYN is present). If SYN is
present the sequence number is the initial sequence
number (ISN) and the first data octet is ISN+1.
 Acknowledgment Number:

32 bits - If the ACK control bit is set this field contains the
value of the next sequence number the sender of the
segment is expecting to receive. Once a connection is
established this is always sent.
 TCP Header Information
 Acknowledgement Number (continued)
 This is for error correction. When a TCP segment is
received without error, the next segment sent out will
have the ACK bit set and this field will have a value
that is at or above the sequence number of the
correctly received segment, plus one, since it is an
indication of the next expected segment. When TCP
receives such an ACK, it can assume that all of its
segmnets with a value below this ACK number have
been received correctly.
 TCP Header Fields (continued)
 Data Offest

4 bits The number of 32 bit words in the TCP Header.
This indicates where the data begins. The TCP header
(even one including options) is an integral number of 32
bits long.
 Reserved - 6 bits must be zero'ed.
 Control Bits






6 bits (from left to right):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
 TCP Header Fields (continued)
 Window:

16 bits - The number of data octets beginning with the one
indicated in the acknowledgment field which the sender of
this segment is willing to accept. This is the TCP's
method of flow control. If a receiver wishes to stop
the sender's sending of data, it can set the window
field in the next segment sent to zero.
 Checksum:

16 bits - The checksum field is the 16 bit one's
complement of the one's complement sum of all 16 bit
words in the header and text. If a segment contains an
odd number of header and text octets to be
checksummed, the last octet is padded on the right with
zeros to form a 16 bit word for checksum purposes.
 The checksum also covers a 96 bit pseudo header
conceptually prefixed to the TCP header. This pseudo
header contains the Source Address, the Destination
Address, the Protocol, and TCP length. This gives the TCP
protection against misrouted segments. This information is
carried in the Internet Protocol and is transferred across the
TCP/Network interface in the arguments or results of calls by
the TCP on the IP.
 The TCP Length is the TCP header length plus the data
length in octets (this is not an explicitly transmitted quantity,
but is computed), and it does not count the 12 octets of the
pseudo header.
IPv4 Header
Vers
VERS
HLEN Service Type
Flags
Identification
Time to Live
Total Length
Protocol
Fragment Offset
Header Checksum
Source IP address
Destination IP address
IP Options (may be null)
Padding
IP Datagram Data (up to 65535 bytes)
DA
SA
Type
0800
IP Header and Data
Ethernet Data Field
CRC
Header Length, Service Type and Total Length
VERS
HLEN
Service Type
Flags
Identification
Time to Live
Total Length
Protocol
Fragment Offset
Header Checksum
Source IP address
Destination IP address
IP Options (may be null)
IP Datagram Data (up to 65535 bytes)
Padding
TTL a critical field used in the Traceroute facility
VERS
HLEN
Flags
Identification
Time to Live
Total Length
Service Type
Protocol
Fragment Offset
Header Checksum
Source IP address
Destination IP address
IP Options (may be null)
IP Datagram Data (up to 65,535 bytes)
Padding
Protocol and Checksum Fields
VERS
HLEN
Flags
Identification
Time to Live
Total Length
Service Type
Protocol
Fragment Offset
Header Checksum
Source IP address
Destination IP address
IP Options (may be null)
IP Datagram Data (up to 65,535 bytes)
Padding
IP Options Field
VERS
HLEN
Flags
Identification
Time to Live
Total Length
Service Type
Protocol
Fragment Offset
Header Checksum
Source IP address
Destination IP address
IP Options (may be null)
IP Datagram Data (up to 65,535 bytes)
Padding
Source and Destination Address Fields
VERS
HLEN
Flags
Identification
Time to Live
Total Length
Service Type
Protocol
Fragment Offset
Header Checksum
Source IP address
Destination IP address
IP Options (may be null)
IP Datagram Data (up to 65,535 bytes)
Padding
 TCP is full-duplex. Any app can send/receive on the same
connection at any time. Therefore TCP must know the windows,
and sequence numbers for both send and receive.
CSE 7348 - class 1
 TCP State machine (three-way handshake)
Client
Server
SYN
Socket
Connect (blocks)
active open
Socket, bind, listen
passive open
SYN K, ack J+1
Connect returns
ack k + 1
 TCP provides connections between clients and servers.
 TCP requires an acknowledgement after transmission.

Implicit in this is the fact that TCP must have some knowledge of
how long to wait.

This in turn requires that TCP must know something of the RTT
(round-trip time) of a given message. This TCP can determine
dynamically.
 TCP associates a sequence number with every byte sent. The
sequence numbers allow segments to be received out-of-order and
correctly reordered before passing to the application layer.

Also provides a way to detect duplicate data.
 TCP also provides flow control via a window which describes the
amount of data a TCP socket will accept. The window is dynamic
adapting to flow.
 The server must be prepared to accept an incoming
connection.
 (sock, bind, listen).
 The client does an ‘active open’ (connect). TCP then sends a
SYN segment (initial sequence number, IP Header, TCP
header and options).
 The server acknowledges the client SYN and the server
sends a SYN (sequence number for any server data). Server
also sends a ACK of the client SYN.

The ACK is the next expected sequence number for the
end sending the ACK.
 The client will acknowledge the server’s SYN.
 Minimum 3 packets.
 Telephone analogy.

Bind is publishing your telephone number.

Listen is turning on the ringer.

Connect is knowing anothers phone number and dialing it.


Accept is when the person being called answers the phone.
• Clients identity being returned is like “Caller ID” (after
answering).
If DNS is being used it is like the phone book.
• gethostbyname
• gethostbyaddr
 TCP Options
 MSS option (maximum segment size). From TCP sending the
SYN. May be different in each direction.
 Window Scale Option. Used to be 216. Now bits can be leftshifted by 0-14 bits.
• What is fastest way to do multiply/divide in assembly
language?
• Series of 2n provides all possible multipliers, divisors.
• Timestamp option (only on latest connectivity).

TCP Connection Termination
• Active close sends a FIN segment.
• Passive close receives FIN. FIN is ACK’ed. FIN is
passed to application as an EOF.
• Passive close will ‘close’ its socket, thereby sending a
FIN.
How many segments are required?
CLIENT
ACTIVE CLOSE
SERVER
FIN M
ACK M+1
FIN N
ACK N + 1
PASSIVE CLOSE
read returns 0
close
 11 states in TCP state machine
CLOSED
CLIENT TRANSITIONS BLUE
SERVER TRANSITIONS red
LISTEN
SYN_RCVD
SYN_SENT
ESTABLISHED
CLOSE_WAIT
FIN_WAIT1
CLOSING
FIN_WAIT2
TIME_WAIT
LAST_ACK