NWelcome to CSE 5348/7348 "Inter and Intra Networking Protocols". nPrimary Text: Richard Stevens...

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 high-altitude. 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.

http://www.netvalley.com/archives/mirrors/cerf-how-inet.txt

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.ohio-state.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

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

Submitting an RFC

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 headerRunning headerNetwork Working GroupNetwork Working Group

Request for Comment < place number here>Request for Comment < place number here>

Obsoletes/Updates: <place RFC number here>Obsoletes/Updates: <place RFC number here>

Category:Category:

TitleTitle

Status of this memoStatus of this memo

AbstractAbstract

Table of ContentsTable of Contents

Author name (firstAuthor name (firstinitial and last name)initial and last name)

Author OrganizationAuthor Organization

Submission DateSubmission Date

Running FooterRunning 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.

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.

Requirements for RFCs

EthernetEthernet Token BusToken Bus Token RingToken Ring FDDIFDDI

Internet ProtocolInternet Protocol

ARPARP

TELNET FTP SMTP DNS SNMP DHCPTELNET FTP SMTP DNS SNMP DHCP

DatalinkDatalinkPhysicalPhysical

NetworkNetwork

TransportTransport

ApplicationApplicationPresentationPresentation

SessionSession

ICMPICMPIGMPIGMP

RTPRTPRTCPRTCP

TransmissionTransmissionControl ProtocolControl Protocol

User DatagramUser DatagramProtocolProtocol

OSPFOSPF

RIPRIP

•TCP/IP and the ISO/OSI Model

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 withinan AS (Autonomous Systems).

EGPs (External Gateway Protocol) are used as routing protocols between ASs.

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

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

WorkstationWorkstation

DataData

TCP SegmentTCP Segment

DatagramDatagram

PacketPacket

ApplicationApplication

TCPTCP

IPIP

Data LinkData Link

FrameFrame

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 FIN: No more data from sender Window:

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

Ethernet Data FieldEthernet Data Field

VersVers HLENHLEN Service TypeService Type Total LengthTotal Length

IdentificationIdentification FlagsFlags Fragment OffsetFragment Offset

Time to LiveTime to Live ProtocolProtocol Header ChecksumHeader Checksum

Source IP addressSource IP address

Destination IP addressDestination IP address

IP Options (may be null)IP Options (may be null) PaddingPadding

IP Datagram Data (up to 65535 bytes)IP Datagram Data (up to 65535 bytes)

VERSVERS

DADA SASA TypeType08000800

IP Header and DataIP Header and Data CRCCRC

VERSVERS






IP Datagram Data (up to 65535 bytes)IP Datagram Data (up to 65535 bytes)

HLENHLEN Service TypeService Type Total LengthTotal Length

Header Length, Service Type and Total Length

VERSVERS HLENHLEN

ProtocolProtocol Header ChecksumHeader Checksum




IP Datagram Data (up to 65,535 bytes)IP Datagram Data (up to 65,535 bytes)

Service TypeService Type Total LengthTotal Length


Time to LiveTime to Live

TTL a critical field used in the Traceroute facility

Protocol and Checksum Fields

VERSVERS HLENHLEN

Time to LiveTime to Live







ProtocolProtocol Header ChecksumHeader Checksum

IP Options Field

VERSVERS HLENHLEN




PaddingPadding




IP Options (may be null)IP Options (may be null)

Source and Destination Address Fields

VERSVERS HLENHLEN








CSE 7348 - class 1

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.

TCP State machine (three-way handshake)

Client Server

Socket, bind, listenpassive open

SYN

SYN K, ack J+1

ack k + 1

SocketConnect (blocks)active open

Connect returns

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 left-shifted

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.• Active close acknowledges this FIN.

CLIENT SERVER

FIN M

ACK M+1PASSIVE CLOSEread returns 0

close

ACTIVE CLOSE

FIN N

ACK N + 1

How many segments are required?

11 states in TCP state machine

CLOSED

LISTEN

SYN_RCVD SYN_SENT

ESTABLISHEDCLOSE_WAIT

LAST_ACKFIN_WAIT1 CLOSING

FIN_WAIT2 TIME_WAIT

CLIENT TRANSITIONS BLUE

SERVER TRANSITIONS red

NWelcome to CSE 5348/7348 "Inter and Intra Networking Protocols". nPrimary Text: Richard Stevens...

Documents

Transcript of NWelcome to CSE 5348/7348 "Inter and Intra Networking Protocols". nPrimary Text: Richard Stevens...