1. nWelcome to CSE 5348/7348 "Inter and Intra Networking Protocols". nPrimary Text: Richard Stevens "Unix Network Programming", Volume 1 nISBN 0-13-490012-X nReference Text: Richard Stevens "Unix Network Programming", Vol 2. nISBN 0-13-081081-9 nInstructor: Mr. Russo

2. nRules of the road: n Basic conversational courtesy is a mandate. n Punctuality is a virtue. nGrading n Objective of the grading process. Historical data n 3 tests: 2 midterms, Final Cheating is NOT TOLERATED in any form. n Grade is calculated based on: 70% from tests scores 15% on Class Participation including presentation 15% on Homework assignments (TA and Instructor Graded).

3. nCommunication: n Office Hours: Friday from 11:00 AM to 2:00 PM in the Adjuncts office. Lab sessions on Thursday evenings as needed. n drusso@seas.smu.edu n 214-549-0960 (email first unless emergency) n 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).

4. n"To not learn from History is to doom oneself to repeat it". nHistory of Computer Communication. n In the beginning, when all was null and void, there was SNA (System Network Architecture) and 3270. IBM Proprietary solution circa mid '70's. n In addition there were other solutions based on XNS (Xerox Network System) such as Novell Netware and Banyan VINES. n DEC had DECnet and LAT (Local Area Transport). n All of these protocols could run over 802.3, 802.5 and FDDI.

5. nThe 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. nGeneral 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.

6. nMany people don't realize that there is more than a metaphor which connects the"Information Superhighway" with the Interstate Highway System. n The Interstate Highway System was not built so you could jump in your SUV and take the family on vacation. n The Roman road system was built to move Legions around the Mediterranean Basin. nIn 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.

7. nARPA - 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." n Sputnik effect: One of the ARPA projects was to develop a communications capability that could survive the adverse effects of nuclear war.

8. nCould the Internet survive a nuclear war? nThe 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. nNikita Kruschev : "In a nuclear war-the living will envy the dead..."

9. nThe 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. nWars 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. nThe 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.

10. n1969: 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...Vinton Cerf n 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.

11. 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.

13. nTCP/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. nThis was particularly difficult in that all computer architectures in that era were highly guarded secrets (nobody would disclose how anything worked - somewhat like microsoft). nThe TCP/IP architectural approach therefore was based on the concept of TCP/IP running as an application. n This allowed the components to function without knowing the details of the foundation OS.

14. nTo facilitate this development DARPA provided grants to UCLA, UCSB and Stanford (SRI). nParallel with the development of TCP/IP many companies were introducing computers, which could communicate using Ethernet (Xerox implementation of 802.3). nSeveral networks were developed employing TCP/IP n CSNET n BITNET n UUCP n USENET n All of this development was undertaken by professors and students.

15. nThe development of the Internet was NOT driven by companies but by the United States Government and Universities. nThe NSF built the NSF network hooking five super computers together. nA provision of attaching to the NSF net was that any attaching network had to be opened to the use of the NSFnet (1986) n 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.

16. nWord spread exponentially about the NSFnet. nSo many requests for connection were received that NSF decided it could no longer support the NSFnet. nThe functional responsibilities of running the NSFnet was passed to several companies. nThese 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. n The NSFnet name was dropped and replaced by the phrase "Internet" (from IP).

17. nThe concept of 'peering' was introduced. The Internet is DEMOCRATIC (therefore it works). nPeering meant that if you wanted to allow access to the Internet by your backbone all other providers could use your backbone for their traffic. nOf course this was a shocking concept to the capitalist business approach: Why should I allow another provider to use my backbone for their traffic? nBecause NSF stated this and the movement to restrict access was tabled.

18. nExample of a real backbone

19. nNAPs are the highest point in the Internet. nMany private backbones are built and connected at NAPs. nNo company 'owns' the Internet or any part of it. nEveryone associated with the Internet has to abide by the rules associated with it. n 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. nIndividual backbone providers then interconnect multiple connections known as Points-Of-Presence (POPs). This is where the user or business connects.

20. The Governing Bodies of the Internet

21. nHow is the Internet managed? nTo some the fact that the Internet functions at all is nothing short of a miracle - thousands of companies must work in complete cooperation. nMillions of people all following one set of rules; particularly unlikely in a field as dedicated to anarchy as software development. nThe Internet is democratic and participatory (as is any effective democracy). nAs the Internet grew various boards and committees were formed to manage the activities.

22. nThe IAB (Internet Architecture Board) governs TCP/IP. nICCB (Internet Configuration Control Board) was setup to help manage the activities of the Internet. n Later the ICCB was disbanded and in its place a number of Task Forces were founded. n The IAB consists of the chairs of the various task forces. nIETF (Internet Engineering Task Force) combined working groups into Areas and designated Area Directors. nAn IESG (Internet Engineering Steering Group) was formed from the various Area Directors.

23. nRequests For Comments (RFC). nA community based method for making changes to the Internet rules and protocols. nAnybody may submit an RFC. nRFC 1543 contains the details on how to submit an RFC. nRFC's 1812, 1122 and 1123 are the most significant RFC's for the TCP/IP suite. nRFCs can be found at http://www.cis.ohio- state.edu/cs/Services/rfc/rfc.html nASSIGNMENT: Graduate Students read RFC 1812 in detail and be ready to discuss in class. nUndergrads: read sections 2 and 3 of RFC 1812.

24. Why Study the RFCs? nRequest for Comments technically define a protocol for the Internet and are informational, or even humorous. nFirst RFC written by Steve Crocker. n Sent via “snail mail” until FTP came along nAn RFC can be submitted by anyone. n Does not automatically become an RFC n First enters as an RFC draft with no number associated n Must follow the instructions for authors detailed in RFC 1543

25. nAnyone can submit an RFC according to RFC 1543. n A major source for RFCs is the Internet Engineering Task Force (IETF) which now has over 75 working groups nThe primary RFC, including all diagrams, must be written in 7-bit ASCII text. nThe secondary publication may be in postscript. nOnce issued, RFCs do not change. n Updated by new RFCs n RFCs can be obsoleted but their numbers are never used again Submitting an RFC

26. RFC Updates nTo join or quit the IETF-Announce list, send an email to: n IETF-Request@cnri.reston.va.us nTo join or quit the RFC-DIST list, send an email to: n RFC-Request@NIC.DDN.MIL

27. RFC Format Running header Network Working Group Request for Comment Request for Comment Obsoletes/Updates: Obsoletes/Updates: Category: Title Status of this memo Abstract Table of Contents Author name (first initial and last name) Author Organization Submission Date Running Footer

28. RFC Format (continued)

29. Other RFC Format Requirements nIntroduction. n 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 nRFC text. n The body of the RFC nDiscussion. n The purpose of this RFC is to focus discussion on particular problems in the Internet and possible solutions nAcknowledgments. n This is where the author may place individual acknowledgment of others

30. Other RFC Format Requirements (continued) nReferences. n 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. nSecurity considerations. n 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. nAuthor’s address. n 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.

31. nMUST–The word or adjective “REQUIRED” means that the item is an absolute requirement of this specification. nMUST NOT–This phrase means the item is an absolute prohibition of this specification. nSHOULD–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. nSHOULD 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. nMAY–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

32. Ethernet Token Bus Token Ring FDDI Internet Protocol ARP TELNET FTP SMTP DNS SNMP DHCP DatalinkPhysical Network Transport ApplicationPresentationSession ICMP IGMP RTPRTCPTransmission Control Protocol User Datagram Protocol OSPF RIP TCP/IP and the ISO/OSI Model

33. IGPs, EGPs, and Routing Protocols nThere is a difference between a routing protocol and a routable protocol. n A routing protocol is one that is used to propagate route path information on a network n A routable protocol is one that has the ability to be routed as opposed to a nonroutable protocol such as NetBIOS nIGPs (Interior Gateway Protocol) are used as routing protocols within an AS (Autonomous Systems). nEGPs (External Gateway Protocol) are used as routing protocols between ASs.

34. nRooted in the early days of the ARPAnet. n Historically tied to the Xerox XNS network operating system nIP is a routable protocol, it needs a routing protocol to route between subnets. nIt is known as a distance vector protocol. nIt builds a table of known networks, which is distributed to other routers. nA hop is one router traversed. Introduction to Routing Protocols

35. Introduction to Routing Protocols (OSPF) nOSPF is an IGP routing protocol. nOperates differently than RIP. nUsed on small, medium, and large networks. n Most beneficial on large, complex networks nIt is a link-state protocol. n It maintains the knowledge of all links (interfaces) in the AS nThe link information is flooded to all other routers in the AS (or area). n All routers receive the same link information nAll routers compute their own tables based on the link information.

36. Other IP-Related Protocols nICMP (Internet Control Management Protocol) is an extension of the IP protocol. n IP is connectionless but connection oriented. n Possible to have errors but they are not reported by IP n ICMP allows for internet devices to transmit error or test messages nIGMP (Internet Group Management Protocol) is also an extension of the IP protocol. n Allows for multicast to operate on an internetwork n Allows hosts to identify the groups they want to the router nARP provides the ability to translate between 48-bit physical-layer addresses and 32-bit IP addresses.

37. Introduction to Transport Layer Protocols nTCP provides for reliable data transfer using sequence numbers and acknowledgments. nUDP provides a simple connectionless transport layer to allow applications access to the IP. nASSIGNMENT: ALL STUDENTS: Read Chapter 1 and 2 in Steven's book Volume 1. nASSIGNMENT: Undergrads: Problem 2.3 and 2.6. Graduate Students Problems 2.3, 2.4, 2.5 and 2.6. nAll 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.

38. Data Encapsulation by Layer Workstation Data TCP Segment Datagram Packet Application TCP IP Data Link Frame

39. nTCP Header

40. nSource Port: n 16 bits - The source port number. nDestination Port: n 16 bits - The destination port number. nSequence Number: n 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.SYN nAcknowledgment Number: n 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.ACK

41. nTCP Header Information nAcknowledgement Number (continued) n 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.

42. nTCP Header Fields (continued) nData 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.options nReserved - 6 bits must be zero'ed. Control Bits n 6 bits (from left to right): n URG: Urgent Pointer field significantUrgent Pointer n ACK: Acknowledgment field significantAcknowledgment n PSH: Push Function n RST: Reset the connection n SYN: Synchronize sequence numberssequence numbers n FIN: No more data from sender Window:

43. nTCP Header Fields (continued) nWindow: 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. nChecksum: n 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.

44. nThe 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. nThe 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.

45. IPv4 Header Ethernet Data Field VersHLEN Service Type Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source IP address Destination IP address IP Options (may be null) Padding IP Datagram Data (up to 65535 bytes) VERS DASA Type0800 IP Header and Data CRC

46. VERS Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source IP address Destination IP address IP Options (may be null) Padding IP Datagram Data (up to 65535 bytes) HLEN Service Type Total Length Header Length, Service Type and Total Length

47. VERS HLEN Protocol Header Checksum Source IP address Destination IP address IP Options (may be null) Padding IP Datagram Data (up to 65,535 bytes) Service Type Total Length Identification Flags Fragment Offset Time to Live TTL a critical field used in the Traceroute facility

48. Protocol and Checksum Fields VERS HLEN Time to Live Source IP address Destination IP address IP Options (may be null) Padding IP Datagram Data (up to 65,535 bytes) Service Type Total Length Identification Flags Fragment Offset Protocol Header Checksum

49. IP Options Field VERS HLEN Time to Live Protocol Header Checksum Source IP address Destination IP address Padding IP Datagram Data (up to 65,535 bytes) Service Type Total Length Identification Flags Fragment Offset IP Options (may be null)

50. Source and Destination Address Fields VERS HLEN Time to Live Protocol Header Checksum IP Options (may be null) Padding IP Datagram Data (up to 65,535 bytes) Service Type Total Length Identification Flags Fragment Offset Source IP address Destination IP address

51. CSE 7348 - class 1 nTCP 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. nTCP State machine (three-way handshake) ClientServer Socket, bind, listen passive open SYN SYN K, ack J+1 ack k + 1 Socket Connect (blocks) active open Connect returns

52. nTCP provides connections between clients and servers. nTCP requires an acknowledgement after transmission. n Implicit in this is the fact that TCP must have some knowledge of how long to wait. n This in turn requires that TCP must know something of the RTT (round-trip time) of a given message. This TCP can determine dynamically. nTCP 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. n Also provides a way to detect duplicate data. nTCP 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.

53. nThe server must be prepared to accept an incoming connection. n(sock, bind, listen). nThe client does an ‘active open’ (connect). TCP then sends a SYN segment (initial sequence number, IP Header, TCP header and options). nThe 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. n The ACK is the next expected sequence number for the end sending the ACK. nThe client will acknowledge the server’s SYN. nMinimum 3 packets.

54. nTelephone analogy. n Bind is publishing your telephone number. n Listen is turning on the ringer. n Connect is knowing anothers phone number and dialing it. n Accept is when the person being called answers the phone. Clients identity being returned is like “Caller ID” (after answering). n If DNS is being used it is like the phone book. gethostbyname gethostbyaddr

55. nTCP Options nMSS option (maximum segment size). From TCP sending the SYN. May be different in each direction. nWindow Scale Option. Used to be 2 16. Now bits can be left- shifted by 0-14 bits. What is fastest way to do multiply/divide in assembly language? Series of 2 n provides all possible multipliers, divisors. Timestamp option (only on latest connectivity). n 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.

56. CLIENT SERVER FIN M ACK M+1 PASSIVE CLOSE read returns 0 close ACTIVE CLOSE FIN N ACK N + 1 How many segments are required?

57. n11 states in TCP state machine CLOSED LISTEN SYN_RCVD SYN_SENT ESTABLISHED CLOSE_WAIT LAST_ACKFIN_WAIT1 CLOSING FIN_WAIT2TIME_WAIT CLIENT TRANSITIONS BLUE SERVER TRANSITIONS red