Welcome to CSE 5348/7348 "Inter and Intra Networking Protocols".

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

2. 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).

3. Communication: • Office Hours: Friday from 11:00 AM to 2:00 PM in the Adjuncts office. • Lab sessions on Thursday evenings as needed. • drusso@seas.smu.edu • 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).

4. "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.

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

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

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

8. 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..."

9. 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 roofand 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.

10. 1969: The firstLOGs: 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.

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

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

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

16. 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).

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

18. Example of a real backbone

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

20. The Governing Bodies of the Internet

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

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

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

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

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

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

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

28. RFC Format (continued)

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

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

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

32. TCP/IP and the ISO/OSI Model Application Presentation Session TELNET FTP SMTP DNS SNMP DHCP RIP RTP RTCP Transmission Control Protocol User Datagram Protocol Transport OSPF ICMP IGMP Internet Protocol Network ARP Datalink Physical Ethernet Token Bus Token Ring FDDI

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

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

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

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

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

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

39. TCP Header

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

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

42. 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:

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

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

45. Vers HLEN Service Type Total Length VERS IPv4 Header Flags Fragment Offset Identification 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) Type 0800 DA SA IP Header and Data CRC Ethernet Data Field

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

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

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

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

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