Subnet Routing Replace Logo

Outline INFOTECH Lecture

IP Based Networks and Applications Manuscript: Edition Summer 2004

Additional material and information on the course is available at http://www.jcho.de/jc/IPNA/

Dr.-Ing. Joachim Charzinski [email protected]

© Joachim Charzinski This slide set is distributed to support students of the University of Stuttgart who attend the IPNA lecture http://www.jcho.de/IPNA/ during summer term 2004. All other use requires written permission by Joachim Charzinski. IPNA – IP based Networks and Applications IPNA – IP based Networks and Applications Table of Contents (2) 2004 Edition Table of Contents 2004 Edition 4. Applications and Application Layer Protocols 4-1 4.1 Introduction 4-5 4.1.1 Design Principles 4-5 1. Introduction 1-1 4.1.2 Contents Delineation 4-6 1.1 Overview of the lecture 1-6 4.1.3 Client-Server Paradigm 4-9 4.1.4 Reply Codes 4-11 1.2 Internet History 1-26 4.1.5 Socket Concept 4-15 1.3 IP Standardisation 1-46 4.2 DNS 4-20 1.4 Networking Basics Refresher 1-55 4.3 E-Mail 4-28 1.4.1 Reference Model 1-56 4.3.1 SMTP 4-32 1.4.2 Circuit Switching and Packet Switching 1-59 4.3.2 MIME 4-37 1.4.3 Local Area Networks 1-65 4.3.3 POP3 4-39 1.4.4 Network Elements 1-76 4.3.4 IMAP 4-42 Questions 1-94 4.4 HTTP 4-43 4.5 Telnet 4-55 2. Network Layer et. al. 2-1 4.6 FTP 4-62 2.1 Internet Reference Model 2-3 4.7 VoIP 4-67 2.2 IP 2-14 4.7.1 Packetized Voice 4-69 2.2.1 IP Packets 2-19 4.7.1 H.323 4-71 2.2.2 Addressing 2-32 4.7.2 SIP 4-78 2.2.3 Fragmentation 2-43 2.3 ICMP 2-50 5. Network Architectures 5-1 2.4 ARP 2-62 5.1 The Internet 5-4 2.5 Routing 2-68 5.2 Local IP Networks 5-6 2.5.1 Principle 2-69 5.3 Intranets 5-13 2.5.2 Algorithms 2-81 5.3.1 Network Address Translation (NAT) 5-15 2.5.3 Protocols 2-86 5.3.2 Virtual Private Networks (VPN) 5-16 2.6 UDP 2-93 5.3.3 Remote LAN Access (RLA) 5-17 Questions 2-99 5.4 Residential Access 5-18 5.5 Voice Carrier Networks 5-22 3. Transport Layer 3-1 5.6 Mobile Networks 5-25 3.1 TCP (Transmission Control Protocol) 3-5 5.6.1 Mobility Support 5-26 3.1.1 Overview 3-6 5.6.2 GPRS 5-29 3.1.2 Reliable Transport 3-8 5.6.3 Header Compression 5-30 3.1.3 TCP Header 3-13 5.6.4 TCP and Packet Loss 5-32 3.1.4 Reliable Transport in TCP 3-22 5.7 Overlay Networks 5-34 3.1.5 Connection Concept 3-28 5.7.1 General View 5-35 3.2 TCP Flow and Congestion Control 3-38 5.7.2 Building Overlays with P2P Mechanisms 5-37 3.2.1 Principle 3-41 Questions 5-39 3.2.2 Congestion Control Algorithms: Tahoe, Reno, Vegas 3-47 3.2.3 TCP Performance 3-56 3.2.4 Extensions 3-61 6. Statistics and Performance 6-1 3.3 Assigned Numbers 3-62 6.1 Introduction 6-4 3.4 Other Transport Protocols 3-66 6.1.1 Basic Statistics 6-4 3.4.1 SCTP 3-67 6.1.2 Classical Models and Results 6-10 3.4.2 RTP 3-71 6.2 Web Statistics 6-13 Questions 3-76 6.2.1 TCP Effects 6-14 6.2.2 Heavy-Tailed Distributions 6-17 6.3 Long-Range Dependence and Self-Similarity 6-21 6.4 Issues with Simulations 6-27 Questions 6-32 IPNA – IP based Networks and Applications IPNA – IP based Networks and Applications Table of Contents (3) 2004 Edition Errata 2004 Edition 7. Quality of Service 7-1 7.1 What is Quality of Service? 7-4 7.2 Best Effort Service 7-9 7.3 Differentiated Services 7-11 7.4 Integrated Services 7-14 7.5 MPLS 7-16 7.6 Service Level Agreements 7-22 Questions 7-24

8. Network Management 8-1 8.1 Introduction 8-4 8.2 Configuration Management 8-7 8.3 Performance Management 8-9 8.4 Fault Management 8-11 8.5 SNMP MIBs 8-14 8.6 SNMP Protocol 8-18 Questions 8-22

9. Security 9-1 9.1 Introduction 9-4 9.2 Methods for Improving Security 9-10 9.2.1 Methods for Confidentiality and Integrity 9-11 9.2.2 Methods for System Security 9-16 9.3 Internet Security Frameworks 9-17 9.3.1 Authentication Frameworks 9-18 9.3.2 Network Layer Security: IPsec 9-19 9.3.3 Transport Layer Security: SSL and TLS 9-21 9.3.4 Application Layer Security: PGP 9-22 9.4 Firewalls 9-23 9.5 Absolute Security? 9-30 Questions 9-31

10. IPv6 10-1 10.1 Introduction 10-4 10.2 Addressing 10-6 10.3 IP Packet Header 10-9 10.4 Automatic Configuration 10-17 10.5 Security Support 10-18 10.6 Changes to Other Protocols 10-19 10.7 Migration Strategies 10-21 Questions 10-24 Outline Preliminary remarks INFOTECH Overview Lecture Internet History IP Standardisation Networking Basics Refresher

Information and Communication Networks

IP Based Networks and Applications Chapter 1: Introduction

Dr.-Ing. Joachim Charzinski [email protected]

Objectives

Preliminary remarks Overview Internet History Learn about and explore IP technology IP Standardisation Networking Basics Refresher See the difference between The Internet and other IP networks

be able to design IP based applications

Not: how to use applications link recommendations for surfing

Preliminary remarks Overview Communications (will be refreshed) Internet History LANs IP Standardisation OSI Reference model Networking Basics Refresher

basic C knowledge to understand examples to apply your new knowledge

how to use the Web and e-mail also for accessing information about this lecture

some maths

LAN Local Area Network © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-3

Remarks

Preliminary remarks Overview “homework” Internet History preparation for next lecture IP Standardisation simple tasks to give you a “hands-on” feeling for the course Networking Basics material Refresher mixture of fun and work no “official” solutions

You can contact me by e-mail: [email protected] (at work) [email protected] (at home)

Additional information for this course is available at http://www.jcho.de/jc/IPNA/

Preliminary remarks Overview 1. Introduction Internet History IP Standardisation 2. Network Layer (et al.) Networking Basics 3. Transport Layer Refresher 4. Applications and Application Layer Protocols 5. Network Architectures 6. Statistics and Performance 7. Quality of Service 8. Network Management 9. Security 10. Ipv6

1.1 Outline Chapter 1: Introduction

Preliminary remarks 1.1 Overview of the lecture Overview Chapter 1 Chapter 2 Chapter 3 Chapter 4 1.2 Internet History Chapter 5 evolution and growth of the Internet Chapter 6 Chapter 7 Chapter 8 Chapter 9 1.3 IP Standardisation Chapter 10 Internet History IP Standardisation 1.4 Networking Basics Refresher Networking Basics 1.4.1 Reference Model Refresher 1.4.2 Circuit Switching and Packet Switching 1.4.3 Local Area Networks 1.4.4 Network Elements

Preliminary remarks 2.1 Internet Reference Model Overview Chapter 1 Chapter 2 2.2 IP Chapter 3 2.2.1 IP Packets Chapter 4 Chapter 5 2.2.2 Addressing Chapter 6 2.2.3 Fragmentation Chapter 7 Chapter 8 2.3 ICMP Chapter 9 Chapter 10 2.4 ARP Internet History IP Standardisation 2.5 Routing Networking Basics 2.5.1 Principle Refresher 2.5.2 Algorithms 2.5.3 Protocols 2.6 UDP

1.1 Outline Chapter 2: Network Layer (et al.) – Preview

Preliminary remarks Overview Major IP based Protocols Chapter 1 replace logo Chapter 2 Chapter 3 Chapter 4 Users... Chapter 5 Chapter 6 Application Programs Chapter 7 Chapter 8 Chapter 9 HTTP Chapter 10 FTP SNMP NFS MIME ASN.1 XDR Internet History SMTP BGP RPC rlogin TELNET DNS TFTP BOOTP RIP RTP RPC &rsh & DHCP IP Standardisation TCP UDP Networking Basics Refresher IP (+ICMP, IGMP) ARP, ATMARP, SLIP, PPP Hardware Device Drivers, Media Access Control Protocols

Source: [Comer 2000] Hardware...

Preliminary remarks 3.1 TCP (Transmission Control Protocol) Overview Chapter 1 3.1.1 Overview Chapter 2 3.1.2 Reliable Transport Chapter 3 Chapter 4 3.1.3 TCP Header Chapter 5 3.1.4 Reliable Transport in TCP Chapter 6 3.1.5 Connection Concept Chapter 7 Chapter 8 Chapter 9 3.2 TCP Flow and Congestion Control Chapter 10 3.2.1 Principle Internet History 3.2.2 Congestion Control Algorithms: IP Standardisation Tahoe, Reno, Vegas Networking Basics 3.2.3 TCP Performance Refresher 3.2.4 Extensions 3.3 Assigned Numbers 3.4 Other Transport Protocols 3.4.1 SCTP 3.4.2 RTP

1.1 Outline Chapter 3: Transport Layer – Preview

Preliminary remarks TCP Congestion Control Overview replace logo Principal Figure Chapter 1 Chapter 2 Chapter 3 TCP TCP Reno trace 35 Chapter 4 Congestion Control Chapter 5 Principle Chapter 6 Algorithms 30 LL LL Chapter 7 Performance LL Extensions 25 Chapter 8 LL Assigned Numbers Chapter 9 20 CACA CA Chapter 10 Other T. Protocols CACA 15 Internet History FR FRFR IP Standardisation 10 S Networking Basics 5 TO SS Congestion Window Size Refresher 0 0 5 10 15 20 25 30

SegmentTime in Number units SS Slow Start FRFR Fast Recovery TOTO Timeout LL Packet Loss CACA Congestion Avoidance

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 3 Edition Summer 2002 3-55 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-10 1.1 Outline – Chapter 4: Applications and Application Layer Protocols

Preliminary remarks 4.1 Introduction 4.4 HTTP Overview Chapter 1 4.1.1 Design Principles Chapter 2 4.1.2 Client-Server Paradigm 4.5 Telnet Chapter 3 4.1.3 Reply Codes Chapter 4 4.6 FTP Chapter 5 4.1.4 Socket Concept Chapter 6 4.7 VoIP Chapter 7 4.2 DNS Chapter 8 4.7.1 Packetized Voice Chapter 9 4.7.1 H.323 Chapter 10 4.3 E-Mail 4.3.1 SMTP 4.7.2 SIP Internet History 4.3.2 MIME IP Standardisation 4.3.3 POP3 Networking Basics Refresher 4.3.4 IMAP

1.1 Outline – Chapter 4: Applications and Application Layer Protocols

Preliminary remarks SMTP Overview replace logo Chapter 1 Conversation Example Chapter 2 Chapter 3 Introduction Chapter 4 Minimum conversation between client (C) and server (S) DNS Chapter 5 E-Mail Chapter 6 S: 220 host-a.net ready Chapter 7 SMTP C: HELO host-b.edu Chapter 8 MIME S: 250 host-a.net Chapter 9 PO P3 C: MAIL FROM: Chapter 10 IMAP S: 250 OK C: RCPT TO: Internet History HTTP C: RCPT TO: Telnet S: 250 OK IP Standardisation C: DATA FTP C: DATA Networking Basics S: 354 Start mail input; end with . VoIP C: Hi, this is my test mail to you all Refresher C: Hi, this is my test mail to you all C: which extends over a few lines C: ... C: . S: 250 OK C: QUIT S: 221 mailserver.mynet closing connection. Thanks for your message.

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Net works IPNA Chapter 4 Edition Summer 2002 4-31 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-12 1.1 Outline Chapter 5: Network Architectures

Preliminary remarks 5.1 The Internet Overview Chapter 1 5.2 Local IP Networks Chapter 2 Chapter 3 5.3 Intranets Chapter 4 5.3.1 Network Address Translation (NAT) Chapter 5 Chapter 6 5.3.2 Virtual Private Networks (VPN) Chapter 7 5.3.3 Remote LAN Access (RLA) Chapter 8 Chapter 9 5.4 Residential Access Chapter 10 Internet History 5.5 Voice Carrier Networks IP Standardisation 5.6 Mobile Networks Networking Basics Refresher 5.6.1 Mobility Support 5.6.2 GPRS 5.6.3 Header Compression 5.6.4 TCP and Packet Loss 5.7 Overlay Networks 5.7.1 General View 5.7.2 Building Overlays with P2P mechanisms © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-13

1.1 Outline Chapter 5: Network Architectures – Preview

Preliminary remarks Overview P2P search Chapter 1 replace logo Chapter 2 Chapter 3 The Internet application layer multicast for searching Chapter 4 Local IP Networks Chapter 5 direct peer-to-peer connection for download Intranets Chapter 6 Chapter 7 Residential Access “looking for file x” Chapter 8 Voice Carriers “give me file x” Chapter 9 Mobile Networks download Chapter 10 Overlay Networks Internet History “I’ve got IP Standardisation file x” Networking Basics Refresher

“I’ve got file x”

real (IP) network topology is different from overlay topology

Preliminary remarks 6.1 Introduction Overview Chapter 1 6.1.1 Basic Statistics Chapter 2 6.1.2 Classical Models and Results Chapter 3 Chapter 4 Chapter 5 6.2 Web Statistics Chapter 6 6.2.1 TCP Effects Chapter 7 6.2.2 Heavy-Tailed Distributions Chapter 8 Chapter 9 Chapter 10 6.3 Long-Range Dependence and Self-Similarity Internet History 6.4 Issues with Simulations IP Standardisation Networking Basics Refresher

1.1 Outline Chapter 6: Statistics and Performance – Preview

Preliminary remarks Measured SMTP Traffic Poisson Traffic Overview 10s Aggregates Chapter 1 over 10000s Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 1s Aggregates Chapter 8 over 1500s Chapter 9 Chapter 10 Internet History

IP Standardisation 0.1s Aggregates i2001 k s n zi r

over 150s a Networking Basics h C m i Refresher h 6/ 06.2001 / © Joac r e t

10ms Aggregates p a h C

over 15s A IPN Information and Communication Networks Joachim Charzinski http://www.ic.siemens.com/networks/ http://www.jcho.de/jc/IPNA/ 6-23

Preliminary remarks 7.1 What is Quality of Service? Overview Chapter 1 7.1.1 General View Chapter 2 7.1.2 QoS Metrics Chapter 3 Chapter 4 7.1.3 Admission Control Chapter 5 Chapter 6 7.2 Best Effort Service Chapter 7 Chapter 8 7.3 Differentiated Services Chapter 9 Chapter 10 7.4 Integrated Services Internet History IP Standardisation 7.5 MPLS Networking Basics Refresher 7.6 Service Level Agreements

1.1 Outline Chapter 8: Network Management

Preliminary remarks 8.1 Introduction Overview Chapter 1 Chapter 2 8.2 Configuration Management Chapter 3 Chapter 4 8.3 Performance Management Chapter 5 Chapter 6 8.4 Fault Management Chapter 7 Chapter 8 Chapter 9 8.5 SNMP MIBs Chapter 10 Internet History 8.6 SNMP Protocol IP Standardisation Networking Basics Refresher

Preliminary remarks Overview Management Architecture Chapter 1 replace logo Chapter 2

Chapter 3 Chapter 8 Architecture Chapter 4 Introduction management station(s) Chapter 5 network elements running Configuration Mgt. Chapter 6 management “agent” software NE Performance Mgt. NE Chapter 7 routers Fault Mgt. Chapter 8 servers NE Chapter 9 SNMP MIBs printer, terminal, NE Chapter 10 SNMP Protocol Web, remote access, . . . Internet History NE NE

IP Standardisation NE NE Networking Basics MS Refresher other Network

Basic Mechanisms request information from an agent set configuration data (center to agent) notify center of new information (“trap”: agent to center)

1.1 Outline Chapter 9: Security

Preliminary remarks 9.1 Introduction Overview Chapter 1 Chapter 2 9.2 Methods for Improving Security Chapter 3 9.2.1 Methods for Confidentiality and Integrity Chapter 4 Chapter 5 9.2.2 Methods for System Security Chapter 6 Chapter 7 9.3 Internet Security Frameworks Chapter 8 9.3.1 Authentication Frameworks Chapter 9 Chapter 10 9.3.2 Network Layer Security: IPSec Internet History 9.3.3 Transport Layer Security: SSL and TLS IP Standardisation 9.3.4 Application Layer Security: PGP Networking Basics 9.4 Firewalls Refresher 9.5 Absolute Security?

Preliminary remarks Overview 9.4 Firewalls Chapter 1 replace logo Chapter 2

Chapter 3 Chapter 9 Chapter 4 Secure a whole enterprise network Introduction Chapter 5 Improving Security Common point of trust Chapter 6 reduces effort in securing many computers Frameworks Chapter 7 reduces risk of a misconfigured computer compromising others’ Firewalls Chapter 8 security Chapter 9 Absolute Security? only one system to verify and observe Chapter 10 only few services need to go across Internet History IP Standardisation Global viceess Internet sseelleecctteed sseerrvic Networking Basics througgh Refresher (insecure) ccaan ppaassss thr

l FFiirreewwalll Intranet (protected)

1.1 Outline Chapter 10: IP Version 6

Preliminary remarks 10.1 Introduction Overview Chapter 1 Chapter 2 10.2 Addressing Chapter 3 Chapter 4 10.3 IP Packet Header Chapter 5 Chapter 6 10.4 Automatic Configuration Chapter 7 Chapter 8 10.5 Security Support Chapter 9 Chapter 10 10.6 Changes to Other Protocols Internet History IP Standardisation 10.7 Migration Strategies Networking Basics Refresher

Preliminary remarks Overview IPv6 Packet Header Chapter 1 replace logo Chapter 2

Chapter 3 Chapter 10 Chapter 4 Concept optional Introduction Chapter 5 Base Extension Extension Addressing . . . Chapter 6 Header Header #1 Header #n User data ... Chapter 7 IP Packet Header Chapter 8 Autoconfiguration Chapter 9 Security Support Base Header Format Chapter 10 Changes to others Version Traffic Class Flow Label Internet History Migration Strategies Payload Length Next Header Hop Limit IP Standardisation Networking Basics Source Address Refresher

Destination Address

Chapter 1: Introduction

Preliminary remarks 1.1 Overview of the lecture Overview Internet History IP Standardisation 1.2 Internet History Networking Basics Refresher evolution and growth of the Internet

1.3 IP Standardisation

1.4 Networking Basics Refresher 1.4.1 Reference Model 1.4.2 Circuit Switching and Packet Switching 1.4.3 Local Area Networks 1.4.4 Network Elements

Preliminary remarks 1960s: studies of packet switching Overview Internet History early 1969: Arpanet contract to BBN IP Standardisation Dec. 1969: four node network between UCLA, UCSB and Networking Basics Refresher Utah 4 IMPs (Interface Message Processor) funded by US ARPA (defense) advance research projects agency (for academia and US military) early inclusion of wireless (ALOHA) and satellite links 1973: first international connections 1979: around 100 nodes

Evolution

Preliminary remarks 1980-1983: Introduction of TCP and IP Overview TCP/IP popular on Unix machines Internet History communication protocols and utilities for remote work IP Standardisation 1984: Domain Name System Networking Basics Refresher 1986: NSFNET (US national science foundation) 1989: 100000 nodes 1989: first Web proposal (Tim Berners-Lee, Robert Cailliau) 1991: gopher 1992: MBONE (multicast for audio and video) 1993: NCSA Mosaic (first widely used Web browser) 1994: Internet known in public (press, adverts, ISPs) 1995: end of the NSFnet backbone Next Generation research networks Internet2, Canarie (1993), ... Everything over IP, IP over everything

Preliminary remarks Early ARPANET maps (1969-1972) Overview from L. Kleinrock, Queueing Systems Vol. 2, 1976 Internet History IP Standardisation Networking Basics Refresher Internet Connectivity Maps from ftp://ftp.cs.wisc.edu/connectivity_table/ mid-of-year versions: v2 9/1991 v6 8/1992 v9 8/1993 v11 7/1994 v14 6/1995 v15 6/1996 v16 6/1997

Arpanet Network Evolution

Preliminary remarks Overview Internet History IP Standardisation Networking Basics Refresher

Components of Growth

Preliminary remarks Number of users Overview users reached by technology Internet History (connectable, owners of access devices) take rate / acceptance IP Standardisation Networking Basics Traffic demand per application Refresher Web item sizes (images, Java applets with menus, audio/video clips) New applications audio/video streaming, 3D chat, software update services (e.g. Windows® 98, ME, XP) e-business Access line bit rate Core network bit rate Number of servers Penetration into leisure / entertainment sector time budget of 2–6 hours per day

Preliminary remarks Overview Internet History IP Standardisation Networking Basics Refresher

Worldwide Internet Connectivity – 8/1992

Preliminary remarks Overview Internet History IP Standardisation Networking Basics Refresher

Worldwide Internet Connectivity – 7/1994

Preliminary remarks Overview Internet History IP Standardisation Networking Basics Refresher

Worldwide Internet Connectivity – 6/1996

Preliminary remarks Overview Internet History IP Standardisation Networking Basics Refresher

Growth – Measures and Data Sources

Preliminary remarks Different measures Overview subnetworks Internet History domains IP Standardisation host names Networking Basics Refresher pingable hosts (always on + ping configured) IP-capable behind firewall reachable by e-mail

Data sources: www.nw.com www.isc.org www.netsizer.com (no longer available?) www.ripe.net

Preliminary remarks 1G Overview Internet History 100M IP Standardisation Networking Basics Refresher 10M

100k

Number of10k Hosts

Host Table 1k Old Domain Survey New Domain Survey RIPE 100 1980 1985 1990 1995 2000 2005

Growth – Ranking

Preliminary remarks Overview No. Most Hosts Most Largest Fastest Internet History per Capita Hosts Domains Growing IP Standardisation 1 USA USA com Colombia Networking Basics Refresher 2 Finland Japan net Ukraine 3 Iceland Canada edu Czechia 4 Canada UK jp Singapore 5 Sweden Germany ca Sweden 6 Norway Italy uk Belgium 7 New Zealand Australia it South Africa 8 Netherlands Netherlands de Argentina 9 Hong Kong Taiwan us Spain 10 Australia France mil Uruguay

Source:Telcordia Netsizer (http://www.netsizer.com/) on April 21, 2001

Preliminary remarks (million users) 11/2000 2/2002 change 9/2002 change Overview Internet History World total 407.1 544.2 + 34% 605.6 + 11% IP Standardisation Africa 3.1 4.1 + 34% 6.3 + 54% Networking Basics Refresher Asia/Pacific 104.9 157.5 + 50% 187.2 + 19% Europe 113.1 171.3 + 51% 190.9 + 11% Middle East 2.4 4.6 + 94% 5.1 + 11% USA+Canada 167.1 181.2 + 8% 182.7 + 1% Latin America 16.5 25.3 + 53% 33.4 + 32%

Source: NUA “educated guess” April 2003 (http://www.nua.ie/) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-41

Distribution of Internet Users

Firewalled Dial-up users users Residential Dial-Up via access users Always on PPP, SLIP Firewalls Always-on xDSL, Cable modem Core Internet full IP reachability Online Services E-Mail Gateways Web Online Srv. users E-Mail only users Gateways (X.400, FIDO) (WAP, iMode) Mobile Internet users

Preliminary remarks Overview There are other networks based on IP protocols, not Internet History necessarily with a direct connection to the Internet: IP Standardisation Networking Basics Refresher Intranets, Extranets

experimental networks

Voice carrier networks

Mobile network backbones

Î See Chapter 5

Chapter 1: Introduction

Preliminary remarks 1.1 Overview of the lecture Overview Internet History IP Standardisation 1.2 Internet History Networking Basics Refresher evolution and growth of the Internet

1.3 IP Standardisation

1.4 Networking Basics Refresher 1.4.1 Reference Model 1.4.2 Circuit Switching and Packet Switching 1.4.3 Local Area Networks 1.4.4 Network Elements

IANA IAB ISOC ICANN

IRTF IETF ISTF IESG Areas . . .

IAB Internet Architecture Board IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Working Groups Assigned Names and Numbers IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IRTF Internet Research Task Force ISOC Internet Society ISTF Internet Societal Task Force

IETF Working Groups

Preliminary remarks Overview Basic Principles Internet History Small focused efforts preferred to larger comprehensive ones IP Standardisation Preference for a limited number of options Networking Basics Refresher Charter Group created with a narrow focus Published goals and milestones Mailing list and chairs' addresses "Rough consensus (and running code!)" No formal voting Disputes resolved by discussion and demonstration Mailing list and face-to-face meetings Decisions made via e-mail (no "final" decisions made at meetings)

Source: http://www.ietf.org/structure.html © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-46 IETF Areas and Working Groups (4/2004: 135 in total)

Preliminary remarks Applications Area (22) Overview e.g. EDI, FTP, Fax, LDAP, Web Internet History General Area (5) IP Standardisation Networking Basics Internet Area (21) Refresher e.g. DNS, DHCP, IPnG, IP over x, mobility Operations and Management Area (24) e.g. AAA, SNMP, several MIBs, policy, mbone Routing Area (14) Security Area (21) Sub-IP Area (1) (IP over optical, MPLS, VPN,) Traffic Engineering Transport Area (27) DiffServ, Telephony, SIP, Media Gateways, NAT, NFSv4, sigtran

IRTF Research Groups

Active IRTF Research Groups Preliminary remarks Anti-Spam* Overview Authentication Authorisation Accounting Architecture Internet History Crypto Forum* IP Standardisation Delay-Tolerant Networking* Networking Basics End-to-End Refresher Group Security* Internet Measurement* IP Mobility Optimizations* Network Management Peer-to-Peer* Routing Services Management "Historical" IRTF Research Groups Building Differentiated Services NameSpace Information Infrastructure Arch. Privacy and Security Digital Rights Management Reliable Multicast Internet Resource Discovery Secure Multicast Interplanetary Internet Searchable Resource Names * new © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-48 IETF Internet Documents

Preliminary remarks Overview Internet Drafts Internet History Working documents (works in progress) IP Standardisation No status of any kind, not archived, deleted after 6 months Networking Basics Announced and disseminated by IETF Secretariat Refresher RFCs (Requests for Comment), since 1969 Archival document series of the IAB Not all RFCs are standards-track Edited, announced, and disseminated by RFC Editor RFC Categories Standards Track Proposed Standard Draft Standard Standard Informational Experimental Historic Source: http://www.ietf.org/structure.html © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-49

IETF Standard Levels

Preliminary remarks Overview Proposed Standard Internet History Complete, credible specification IP Standardisation Demonstrated utility Networking Basics At least 6 months, no longer than 2 years, then either elevated, Refresher depreciated, or recycled Draft Standard Multiple, independent, interoperable implementations Limited operational experience - works well At least 4 months, no longer than 2 years, then either elevated, depreciated, recycled, or back to Proposed Standard Demonstrated operational stability "The real thing" Can stay forever, or can be depreciated to Historic (new versions must start over from the beginning)

Source: http://www.ietf.org/structure.html © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-50 IETF Standards

Open Standards Preliminary remarks vendor independent Overview see also RFC2026 Internet History IPR not welcome IP Standardisation Networking Basics free distribution Refresher via Internet, see http://www.ietf.org/rfc.html no charges (compare this to ITU, ISO, ANSI, IEEE, ...) multi-platform format → pure ASCII text! emphasis on readability and clarity benefit from implementation (“running code”) availability at time of writing Well-defined requirement levels (RFC2119) MUST / REQUIRED (absolute requirement) MUST NOT / SHALL NOT (prohibited) SHOULD / RECOMMENDED (required in full implementation) SHOULD NOT / NOT RECOMMENDED (use only if absolutely needed) MAY / OPTIONAL (use if you like) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-51

IETF Useful URLs

Preliminary remarks Overview IETF Home Page http://www.ietf.org/ Internet History IP Standardisation RFCs http://www.ietf.org/rfc.html Networking Basics The Tao of the IETF http://www.ietf.org/tao.html Refresher Novices‘ Guide http://www.imc.org/novice-ietf.html IESG Status Page http://www.ietf.org/IESG/status.html Working Group http://www.ietf.org/html.charters/wg-dir.html IETF Monthly Status Reports http://www.ietf.org/IMR/ Additional Information http://www.ietf.org/intro.html April Fools RFCs http://www.2meta.com/april-fools/collections/rfc/

Preliminary remarks 1.1 Overview of the lecture Overview Internet History IP Standardisation 1.2 Internet History Networking Basics Refresher evolution and growth of the Internet Reference Model CS and PS LANs 1.3 IP Standardisation Netw. Elements

1.4 Networking Basics Refresher 1.4.1 Reference Model 1.4.2 Circuit Switching and Packet Switching 1.4.3 Local Area Networks 1.4.4 Network Elements

1.4 Networking Basics Refresher

1.4.1 Reference Model

E-Mail Mail Server Client Internet (sendmail) OSI (netscape)

Application Session SMTP SMTP Representation Layer Application

Transport Transport Layer TCP TCP Layer

Internet- IP IP Network IP IP work Layer Routing Routing Layer

Subnetwork Link Layer Layer PPP PPP ATM ATM Eth. Ethernet + PHY

End Network Network End System Node Node System

Reference Model

Used to clarify functions in network nodes and protocols Preliminary remarks Overview often gives “natural” protocol interfaces Internet History vertical interface: adjacent layer protocol IP Standardisation horizontal interface: peer-to-peer protocol Networking Basics classification of classical functions / network ranges Refresher Physical Layer: bit and byte transmission technology, physical Reference Model CS and PS connection LANs Logical Link Layer, Subnetwork Layer: Netw. Elements ~packet transmission on one physical network Network Layer, Internetwork Layer: Communication over multiple networks Transport Layer: end-to-end communication Higher layers / Application Layer: application specific protocols and services, e.g. HTTP for Web browser/server communication Layers are relative to one networking paradigm e.g. ISDN (L3) can be used as L1/2 for Internet access IP (L3) can be tunneled over IP (L3)

1.4.2 Circuit Switching and Packet Switching

Circuit Switching Example Telephone Connections

Preliminary remarks Overview (explained during lecture) Internet History IP Standardisation Networking Basics Refresher Reference Model CS and PS LANs Netw. Elements

Preliminary remarks Overview A circuit can be ... Internet History a physical line IP Standardisation a time slot in a frame in a TDM system Networking Basics a carrier frequency in an FDM system Refresher a wavelength in a WDM system Reference Model CS and PS a code in a CDMA system LANs Netw. Elements A connection - during its existence - uses one circuit ... or a selection of circuits in parallel (multichannel switching) connection set-up find path through network and through switches towards destination establish path communiation send fixed data rate into the connection release connection after use

Packet Switching (PS)

Preliminary remarks Overview Send packets of data Internet History instead of a fixed bit or byte rate IP Standardisation idle time between packets can be used by other Networking Basics communication relations Refresher variable data rate is possible Reference Model CS and PS connectionless (CL) or connection oriented (CO) modes LANs Netw. Elements Examples: Circuit Packet Switching Switching Connection Telephone, X.25, ATM oriented ISDN Connection Internet less

Preliminary remarks Overview Connection establishment before data transmission Internet History routing performed only for connection establishment IP Standardisation data transmitted along established pat Networking Basics data packets only carry connection identifier Refresher for packet switching: "virtual connection" Reference Model CS and PS LANs Netw. Elements connection state (next hop address) stored in network elements along the path

destination address given during connection set-up

"meta signalling" or default signalling connections needed

Connectionless Packet Switching

Preliminary remarks Overview Data packets transmitted without connection on Network Internet History Layer IP Standardisation Networking Basics routing performed along with forwarding for each packet Refresher but: route cache Reference Model CS and PS destination address carried in each packet LANs Netw. Elements no network layer signalling needed no information stored in network nodes along the path network nodes are less complex cheap high speed packet forwarding "KISS": keep it simple and stupid

higher layer connections can survive network path outages

Wide Area Network

1.4.3 Local Area Networks

Preliminary remarks What is a LAN? Overview Multiple systems attached to a shared medium Internet History “high” total bandwidth, shared by the stations IP Standardisation “low” delay Networking Basics Refresher “low” error rate Reference Model broadcast/multicast capability CS and PS single message (frame) transmitted once LANs Netw. Elements and received by multiple recipients limited geography (max. some km) limited number of stations (max. few hundred) all stations are equivalent (no master/slave) privately operated, not governed by telecommunications regulations (i.e. “data communication” in contrast to “telecommunication”)

[Perlman 1999 p. 19f.] © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-64 LAN IEEE 802 Standards

Preliminary remarks IEEE 802 committee standardises LANs: Overview General Issues, Addressing, Management 802.1 Internet History IP Standardisation MAC (Media Access Control) Layer Networking Basics Refresher 802.3 CSMA/CD (similar to Ethernet) Reference Model 802.4 Token Bus CS and PS 802.5 Token Ring LANs Netw. Elements 802.6 DQDB

LLC (Logical Link Control) 802.2 Type 1: datagram (no functionality) Type 2: reliable, connection oriented HDLC (high-level data link control) on top of LAN frames

CSMA/CD Carrier Sense Multiple Access / Collision Detection DQDB Distributed Queue Dual Bus © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-65

Addresses

Preliminary remarks In communication from a source to a destination: Overview Name Internet History identifies a resource (“identifier”) IP Standardisation independent of location of both source and destination Networking Basics Refresher Address Reference Model tells where something is CS and PS may depend on the location of the destination LANs Netw. Elements Route tells how to get from a source to a destination depends on locations of source and destination (“go left, then take the third turn right”)

[Perlman 1999] © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-66 IEEE LAN Addresses

Preliminary remarks Overview 16 bit addresses (option in the IEEE standards) Internet History enough for any LAN if configured during network start-up IP Standardisation not used Networking Basics Refresher 48 bit addresses for Ethernet / 802.3 LAN interfaces Reference Model initialised by hardware manufacturers in a globally unique way CS and PS first 3 octets: vendor code (organizationally unique identifier, LANs Netw. Elements OUI) last 3 octets: unique hardware ID e.g. “00-60-8c-f9-cf-30” Vendor: 3com Interface ID

see http://standards.ieee.org/regauth/oui/oui.txt Bit and byte orders depend on LAN standard

Frame Formats

Preliminary remarks Overview Ethernet Frame (not to scale) Internet History Destination Source Proto- IP Standardisation Preamble Frame Data FCS Address Address col Networking Basics Refresher Octets: 8 6 6 2 46–1500 4 Reference Model CS and PS IEEE 802.3 Frame (not to scale) LANs Netw. Elements Destination Source Preamble Frame Data FCS CTL SSAP Address Address DSAP Length Octets: 8 6 6 2111 43–1497 4

Protocol > 1500 distinguishes Ethernet from 802.3 DSAP=SSAP=170 (dec) -> SNAP

CTL Control Field DSAP Destination Service Access Point FCS Frame Check Sequence SNAP Subnetwork Access Protocol SSAP Source Service Access Point © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-68 LAN Addresses

Preliminary remarks Overview LAN Addresses must be unique on a LAN Internet History ensured e.g. by globally unique 48 bit IEEE addresses IP Standardisation Networking Basics hosts interface listens to all frames Refresher interface card generates interrupt only for frames with Reference Model CS and PS destination address = local address LANs or Netw. Elements destination address = broadcast address or destinatio address = supported multicast address Sending point-to-point higher layer information in broadcast packets generates excessive interrupt load on all machines!

Q: How do you find out the LAN address of a destination host?

CSMA/CD

Preliminary remarks Overview Carrier Sense Internet History listen before transmission IP Standardisation Networking Basics Multiple Access Refresher medium is shared between multiple stations Reference Model CS and PS Collision Detect LANs monitor while transmitting Netw. Elements detect multiple simultaneous transmissions back off (random time, increased after collisions) Minimum Frame length determined by collision detection! shorter data must be padded

CSMA Carrier Sense Multiple Access CD Collision Detection

Preliminary remarks Overview Internet History S1 starts sending S1 S2 IP Standardisation a very short frame Networking Basics Refresher Reference Model S1 S2 CS and PS LANs Netw. Elements S1 S2 S2 starts sending

S1 S2 S2 detects collision

Collision invisible S1 S2 outside red area

Minimum Frame Length for Ethernet

Maximum Wire Length 2500m Transmission Speed 10 Mbit/s Speed of Electricity on Wire at least 100000 m/s

Preliminary remarks Point to point PHY layer connections Overview from circuit switched PCM telephone network Internet History IP Standardisation Name Bit Rate Voice Circuits Networking Basics Refresher B channel 64 kbit/s 1 Reference Model T1 1.544 Mbit/s 24 CS and PS

US T2 6.312 Mbit/s 96 LANs Netw. Elements T3 44.736 Mbit/s 672 E1 2.048 Mbit/s 30 E2 8.448 Mbit/s 120

Europe E3 34.368 Mbit/s 480 OC-1 51.840 Mbit/s 810 OC-3 155.520 Mbit/s 2430 OC-12 622.080 Mbit/s 9720 OC-24 1244.160 Mbit/s 19440 US Optical OC-48 2488.320 Mbit/s 38880

Plus more details (e.g. concatenation) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-73

1.4.4 Network Elements

Preliminary remarks Repeater Overview Hub Internet History IP Standardisation Networking Basics Bridge Refresher Reference Model Switch CS and PS LANs Netw. Elements Router

Proxy

Gateway

Î These names are not always used consistently!

Preliminary remarks Thick Ethernet (Yellow Cable, 10Base5) Overview 2.5m min. Length 500m max. Internet History TM TM TC TC TC TC IP Standardisation Networking Basics AUI Cable pmeenntt xpeennssiivvee eeqquuiipm Refresher < 48m S eexp S3 4 ployy Reference Model hhaarrdd ttoo ddeeplo S1 CS and PS S2 LANs Netw. Elements Thin Ethernet (Cheapernet, 10Base2) BNC 0.5m “T” plug max. length min. 185m TM TM TC S S 3 4 t: p equuipipmmeenntt bbuut: AUI Cable cchheeaap eq ! S2 ts oofffafaiilluurree! any ssiinngglele ppooiinnts S1 mmany

AUI Attachment Unit Interface MAU Media Attachment Unit BNC Bayonet Neill-Concelman SStation British National Connector TC Transceiver Bayonet Nut Couplers TM Termination (50Ω) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-75

Repeater

Preliminary remarks Overview Length 500m max. Internet History TM TM IP Standardisation TC TC TC TC TC Networking Basics lowss Refresher RReeppeeaatteerr aalllow Reference Model S tensiioonn ooff S3 4 eexxtens CS and PS mennttss S nneettwwoorrkk sseeggme LANs 1 S2 Netw. Elements REP rt MMuultltiippoort S7 S8 S9 S10 eateerr RReeppeat REP TC TC TM TM TC TC

AUI Attachment Unit Interface REP Repeater S S6 5 SStation TC Transceiver TM Termination (50Ω) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-76 Repeater

Preliminary remarks Overview Physical Layer interconnection element Internet History IP Standardisation Networking Basics overcomes signal quality based Ethernet length limitations Refresher at most two repeaters between any two machines Reference Model CS and PS operates on analog electrical signals LANs Netw. Elements

no configuration necessary

Hub

is just a multiport repeater A Wheel Preliminary remarks Overview extensions SpokesSpokes Internet History learning hub / switching hub IP Standardisation - forwards packets Networking Basics only to the right destination ports Refresher - pretends collision on other ports Reference Model -> security feature CS and PS HubHub managed hub LANs Netw. Elements

Twisted Pair Ethernet (10BaseT) r Caabbllee oorr S S CCrroossssoovveer C 4 6 t neeeddeedd S UUpplliinnkk ppoorrt ne 3 ubss “Uplink” toto ccoouuppllee HHub Hub Hub S7 S2 S TP Cable TC AUI Cable 8 S1 AUI Attachment Unit Interface S5 TC Transceiver TP Twisted Pair © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-78 Bridge

Preliminary remarks Overview Standardized in IEEE 802.1 Internet History IP Standardisation like a hub, but talks the Media Access Control protocol Networking Basics can convert between different MACs Refresher Reference Model CS and PS Functions LANs Netw. Elements Store & Forward LAN packets (“frames”) keep collisions local to one network -> limit collision domains -> overcomes MAC related Ethernet length limitations retry packet transmission after collision Learn station addresses Spanning Tree algorithm

IEEE Institute of Electrical and Electronics Engineers LAN Local Area Network MAC Media Access Control © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-79

Bridge Learning

Preliminary remarks Overview Listen promiscuously on every port, receive every packet Internet History IP Standardisation Networking Basics for each packet received, store the source address and Refresher corresponding input interface in a Station Cache Reference Model CS and PS LANs Netw. Elements for each packet received: look for the destination address in the Station Cache if found: forward packet only to corresponding interface (if the packet is coming from this interface, drop it) if not found, forward packet to all interfaces except the one it was coming from ageing of Station Cache: remove entries after some idle time to allow network reconfiguration

1. Station cache is empty AddrAddr Port Port

Addr Port 2. Packet from A to C Src=A, Dst=C; data... 8. Store D Addr Port A1 received at port 1 in station cache A1 C2C2 3. Store A in station cache AddrAddr Port Port 9. Do not forward D2D2 A1A1 the packet 4. Forward packet to port 2

5. Packet from C to A Src=C, Dst=A; data... Port 1 Port 2 received at port 2 Bridge

6. Store C in station cache AddrAddr Port Port A1A1 A B C D C2C2 city Trraafffificc CCaappaacity T ed can bbee iinnccrreeaassed 7. Packet from D to C Src=D, Dst=C; data... can received at port 2 Addr Address Dst Destination Address Src Source Address © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-81

Bridge Spanning Tree

Preliminary remarks Overview The described learning scheme also works for Internet History more than two ports IP Standardisation multiple hops Networking Basics Refresher The simple scheme does not work for multiple paths! Reference Model only for pure tree based topologies CS and PS LANs Netw. Elements 1. Station caches are empty 2. A transmits a packet A 3. Bridge 1 forwards it to LAN 2 LAN 1 and stores “A is on LAN 1” 4. Bridge 2 forwards it to LAN 1 Bridge 1 Bridge 2 and stores “A is on LAN 2”

LAN 2 5. Packet circulates infinitely

LAN Local Area Network © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-82 Bridge Spanning Tree (2)

Preliminary remarks Bridges use a “spanning tree” algorithm to convert any Overview topology into a loop-free subset Internet History IP Standardisation protocol uses configuration messages (“configuration bridge Networking Basics protocol data units”) Refresher Reference Model CS and PS steps at each bridge during configuration BPDU exchange: LANs Netw. Elements 1. Elect one single bridge to be the Root Bridge (lowest ID) 2. Calculate distance of shortest path from this bridge to the root bridge 3. For each LAN, elect a Designated Bridge (closest to the root bridge) 4. Choose a port (“root port”) that gives the best path from this bridge to the Root Bridge 5. Root port plus the ports on which this bridge has been elected Designated Bridge will be included in the spanning tree

BPDU Bridge Protocol Data Unit ID Identifier © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-83

Bridge Spanning Tree (3)

Preliminary remarks Overview Internet History B LoopsLoops IP Standardisation B Networking Basics Refresher Reference Model B CS and PS LANs DeactivatedDeactivated Netw. Elements LinksLinks B B B

B Bridge LAN © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-84 Remote Bridge

Preliminary remarks Overview Two or more bridges interconnected Internet History by point-to-point links IP Standardisation by WAN interconnections Networking Basics Refresher Reference Model CS and PS LANs Point-to-point link Netw. Elements B B

B Bridge LAN © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-85

Bridge Issues

Preliminary remarks Auto-configuration Overview higher total throughput if network is well layed out Internet History generally transparent IP Standardisation but Networking Basics Refresher packets lost after being successfully transmitted by sender Reference Model delay increases CS and PS residual error rate can increase LANs Netw. Elements (CRC may be recalculated at bridges) packet misordering possible (but unlikely) packet duplication possible (but unlikely) problems with different frame sizes conversion from IEEE 802.3 to Ethernet can occur Problems multiply-attached stations with the same link address on all interfaces “pure traffic sink” stations: location will never be known → broadcast © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-86 What is a Switch?

Preliminary remarks Overview A) Term for a Bridge with many ports Internet History e.g. Ethernet Switch IP Standardisation Networking Basics Refresher B) Term for a telecommunications device Reference Model e.g. Voice Switch, ATM Switch CS and PS LANs Netw. Elements C) Term for a combination of bridging and routing functions from Multiport Ethernet bridge with IGMP snooping to configurable setting of routed / bridged ports

D) Term for any fast and modern network interconnection device e.g. “Layer 4+ Switch”

ATM Asynchronous Transfer Mode ... IGMP Internet Group Management Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-87

Router

Preliminary remarks Overview Interconnection device working on the Network Layer Internet History based on worldwide IP instead of LAN addresses IP Standardisation Networking Basics Refresher configuration of routes to destination networks Reference Model CS and PS manual configuration LANs self-configuration Netw. Elements

routing protocols to discover network topology and optimise routes huge routing tables with >10000 entries in backbone routers potentially instable routes see Chapter 2

Preliminary remarks Overview A Transport or Application Layer interconnection device Internet History IP Standardisation Proxy Networking Basics Proxy Refresher B‘ A‘ Reference Model CS and PS LANs A Network Netw. Elements A B Network B

In a communication between A and B, the proxy acts as B to A and as A to B e.g. Proxy Server if A is a client and B is a server

Gateway

Preliminary remarks Overview A Transport or Application Layer interconnection device Internet History IP Standardisation Networking Basics works like a proxy but usually translates between different Refresher protocols, e.g. Reference Model CS and PS SMTP ↔ X.400 Mail Gateway LANs SMTP ↔ FTP Order FTP files via e-mail Netw. Elements Telnet ↔ X.29 PAD access X.29 hosts via telnet FTP ↔ FTAM FTAM servers‘ last chance to survive

Also (in some RFCs): another name for “Router”

FTAM File Transfer, Access and Management FTP File Transfer Protocol RFC Request for Comment SMTP Simple Mail Transfer Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 1 Edition Summer 2004 1-90 Network Interconnection Elements Summary

Preliminary remarks Overview Internet History IP Standardisation Application Proxy Gateway Networking Basics Layer Refresher Transport Reference Model Proxy Gateway CS and PS Layer LANs Netw. Elements Internet- work Layer Router “Gateway”

Subnetwork Layer Bridge Switch

PHYsical Layer Repeater Hub

Questions

Preliminary remarks Overview 1.1 Who is the manufacturer of the LAN card Internet History with address 00-02-b9-2a-13-43? IP Standardisation Networking Basics 1.2 How do you find out the LAN address of your Refresher communication partner? 1.3 Look for the TCP standard on the Web. Questions 1.4 Look for the IEEE 802.3 standard on the Web.

1.5 What does the ping tool do? 1.6 How does it work? 1.7 What are the well-known port numbers for http, https, telnet, ftp?

Information and Communication Networks

IP Based Networks and Applications Chapter 2: Network Layer (et al.)

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

1. Introduction 2. Network Layer (et al.) 3. Transport Layer 4. Applications and Application Layer Protocols 5. Network Architectures 6. Statistics and Performance 7. Quality of Service 8. Network Management 9. Security 10. Ipv6

Reference Model 2.1 Internet Reference Model IP ICMP 2.2 IP ARP 2.2.1 IP Packets Routing 2.2.2 Addressing UDP 2.2.3 Fragmentation 2.3 ICMP 2.4 ARP 2.5 Routing 2.5.1 Principle 2.5.2 Algorithms 2.5.3 Protocols 2.6 UDP

Internet Reference Model – Example replace logo

Web Client Web Server Internet (e.g. (e.g. OSI netscape) Apache)

Application Session, HTTP HTTP Representation, Layer Application

Transport Transport Layer TCP TCP Layer

Internet- IP IP Network IP IP work Layer Routing Routing Layer

Subnetwork Link Layer Layer PPP PPP Eth. Eth. Eth. Ethernet + PHY

End Network Network End System Node Node System

Reference Model IP ICMP ARP Application Proxy Gateway Routing Layer UDP Transport Layer Proxy Gateway

Internet- work Layer Router “Gateway”

Subnetwork Layer Bridge Switch

PHYsical Layer Repeater Hub

Internet Architecture replace logo

Reference Model physical networks interconnected by a router IP ICMP ARP Network 1 Network 2 Routing Router UDP

Interconnection via another network

Network 1 Network 3 R2

R1 Network 2

Reference Model Interconnection of Packet Switching networks IP use the services that the PS networks provide ICMP adapt packet lengths to supported lengths (fragmentation) ARP Routing “Best Effort” delivery UDP no prevention of packet loss independent treatment of packets (no “flow” concept in normal IPv4) sequence integrity not guaranteed

Routers use destination network, not host address need only to know how to reach a network no influence of source host on route (normal IPv4)

no knowledge of full path to destination necessary send to “next hop”

Internet Protocols replace logo

Reference Model IP ICMP HTTP SMTP POP3 FTP NNTP Telnet ...... NFS DNS SNMP ARP TCP UDP Routing (streams in connections) (API for IP) UDP IP (Internet Protocol) Subnetwork (Ethernet, AAL5/ATM, Frame Relay, PPP/ISDN, etc.)

global addresses Introduction of new applications: port numbers advertise port number protocol number instant worldwide reachability IP addresses software distributed via HTTP or FTP subnetwork addresses

Reference Model Used to clarify functions in network nodes and protocols IP often gives “natural” protocol interfaces ICMP vertical interface: adjacent layer protocol ARP horizontal interface: peer-to-peer protocol Routing classification of classical functions / network ranges UDP Physical Layer: bit and byte transmission technology, physical connection Logical Link Layer, Subnetwork Layer: ~packet transmission on one physical network Network Layer, Internetwork Layer: Communication over multiple networks Transport Layer: end-to-end communication Higher layers / Application Layer: application specific protocols and services, e.g. HTTP for Web browser/server communication Layers are relative to one networking paradigm e.g. ISDN (L3) can be used as L1/2 for Internet access IP (L3) can be tunneled over IP (L3)

Reference Model (2) replace logo

Reference Model IP In reality: ICMP ARP Routing Adjacent layers need not be independent UDP e.g. TCP/IP or UDP/IP no other Network Layer protocol defined use tunneling if necessary, but mind the overhead

no “adjacent layer protocol” function calls (blocking), API event queues monolithic implementation

see the sections on Sockets

Users... Application Programs

HTTP FTP SNMP NFS MIME ASN.1 XDR SMTP BGP RPC rlogin TELNET DNS TFTP BOOTP RIP RTP RPC &rsh & DHCP TCP UDP IP (+ICMP, IGMP) ARP, ATMARP, SLIP, PPP Hardware Device Drivers, Media Access Control Protocols

Source: [Comer 2000] Hardware...

“Hourglass” Model replace logo

Reference Model IP ICMP ARP All applications run over IP Routing different UDP applications

different network technologies IP runs over all networks

Source: [Comer 2000] © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-12 Protocol Stack replace logo

Reference Model IP What is a protocol stack? ICMP ARP A selection of protocols, one for each layer Routing describing an implementation / a system UDP known to work in this combination not all protocols are interchangeable layers above IP are usually independent of layers below IP content format can be important as well Examples: G.723.1 HTTP RTP DNS IP TCP UDP UDP AAL5 IP IP IP ATM

Chapter 2: Network Layer (et al.) replace logo

Reference Model 2.1 Internet Reference Model IP IP Packets Addressing 2.2 IP Fragementation 2.2.1 IP Packets ICMP 2.2.2 Addressing ARP 2.2.3 Fragmentation Routing 2.3 ICMP UDP 2.4 ARP 2.5 Routing 2.5.1 Principle 2.5.2 Algorithms 2.5.3 Protocols 2.6 UDP

Reference Model IP IP Packets Is IP a protocol at all? After all, there’s no interaction! Addressing Fragementation ICMP ARP What is a protocol? Routing a convention of data formats UDP a convention of what data units signify a convention of the interaction of state machines

IP is a protocol, even if there are no state machines involved wait for TCP, if you desperately need some ☺

Why not use a purely bridged network? replace logo

Reference Model IP IP Packets What do we need IP or the Network Layer for? Addressing Fragementation ICMP Consider a pure bridged network ARP each end system has its Link Layer address built in Routing each bridge knows all end systems UDP broadcasts reach all nodes

Hierarchy needed to reduce effort in computing routes / spanning tree in storing end system addresses Divide the worldwide network into several smaller bridged networks

Reference Model End systems IP have a network (IP) address assigned to each network interface IP Packets have neighbour router(s) configured (default route, configured Addressing routes) Fragementation communicate within local network using Link Layer addresses ICMP ARP Routing Routers (Intermediate Systems) UDP either: have a next hop entry for all IP networks (not: nodes!) or (like above): know all IP networks on one side and have a default router configured on the other static routes configured (configuration / network management task) dynamic routes are discovered using routing protocols (communication with neighbour routers) for each packet received: look up next hop and forward packet to next hop using the appropriate Link Layer method

IP Protocol Functions replace logo

Reference Model IP IP Packets Connectionless, unreliable best-effort delivery of data Addressing Fragementation ICMP Datagram addressing and forwarding ARP IP header check Routing UDP payload delineation segmentation and reassembly (“fragmentation”) error reporting (ICMP)

optional: route recording source routing

Reference Model IP IP Packets IP packet also called “datagram” Addressing Fragementation IP packet header transmitted before user data ICMP ARP Header User data ... Routing UDP

maximum total length: 65535 bytes minimum total length: 20 bytes (minimum header and no payload)

IP Packets replace logo Header Format

Reference Model Bit positions: IP 0 1 2 3 IP Packets Addressing 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Fragementation Version IHL Type of Service Total Length ICMP ARP Identification Flags Fragment Offset Routing Time to Live Protocol Header Checksum UDP Source Address Destination Address Options Padding

User data ...

Source: RFC791 (September 1981) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-20 IP Packet replace logo Header Fields

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address Version (4 bits) Destination Address

Options Padding

User data ... Version 4: RFC791 (described in the following)

IHL, Internet Header Length (4 bits) counts the number of 32bit words in the header

Version IHL Type of Service Total Length Identification Flags Fragment Offset points to first data word Time to Live Protocol Header Checksum

Source Address Destination Address minimum = 5 (20 byte header) Options Padding

User data ...

IP Packet replace logo Header Fields (2)

Type of Service (8 bits) Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum bit:012 34567

Source Address

Destination Address Options Padding Precedence D T R 0 0 User data ... Precedence Values 111 Network Control (inside a network) 110 Internetwork Control reserved reserved 101 CRITIC / ECP

(see table 100 Flash Override to the right) 011 Flash 1 = Low Delay 010 Immediate 001 Priority 1 = High Reliability

1 = High Throughput 000 Routine

influence on queueing may have influence on routing decision can be coupled to lower layer service classes

policy framework needed for general use -> IETF “Differentiated Services” (DiffServ, DS) activities see Chapter 7 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-22 IP Packet replace logo Header Fields (3)

Version IHL Type of Service Total Length Total Length (16 bits) Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address length of the datagram (in octets), including IP header and data Destination Address

Options Padding

User data ... at most 65535 octets all hosts must be able to accept a datagram of 576 octets (512+64) only send datagrams longer than 576 octets if the receiver can handle them

Version IHL Type of Service Total Length Identification (16 bits) Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address identification of transmitted datagram Destination Address

Options Padding

User data ... unique for transmitter (for the next 65535 packets) used by receiver to reassemble fragmented datagrams

Version IHL Type of Service Total Length Control Flags (3 bits) Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address Bit 0: must be zero (“MBZ”) Destination Address Options Padding Bit 1: DF 1 = don’t fragment 0 = may fragment User data ... Bit 2: MF 1 = more fragments 0 = last fragment

Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address Fragment Offset (13 bits) Destination Address Options Padding counts 8 octet (64 bits) words User data ... indicates where the current fragment belongs in the datagram © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-23

IP Packet replace logo Header Fields (4)

Time to Live (TTL) (8 bits) Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address indicates the maximum residual time the datagram is allowed to Destination Address Options Padding remain in the network User data ... RFC791: “measured in seconds“, but: each router must decrement the TTL value by 1 -> effectively implemented as “residual hop count” necessary to avoid infinitely circling packets in the case of a routing loop (special problem of connectionless packet switching!)

Protocol (8 bits) Version IHL Type of Service Total Length

Identification Flags Fragment Offset Time to Live Protocol Header Checksum indicates the next layer protocol (usually transport layer) Source Address

Destination Address

Options Padding User data ... EGP Exterior Gateway Protocol Some Protocol Numbers ICMP Internet Control Message Protocol from RFC 1700: “Assigned Numbers” IGMP Internet Group Management Protocol IGP Interior Gateway Protocol 1ICMP 9IGP IGRP Cisco Interior Gateway Routing Protocol 2IGMP 17UDP IP Internet Protocol 4IP 46RSVP NHRP Next Hop Resolution Protocol RSVP Resource Reservation Protocol 6 TCP 58 NHRP TCP Transmission Control Protocol 8EGP 88IGRP UDP User Datagram Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-24 IP Packet replace logo Header Fields (5)

Header checksum (16 bits) Version IHL Type of Service Total Length

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address checksum computed on the IP header Destination Address Options Padding re-computed at every node that changes the header (e.g. the User data ... TTL field!) 16 bit one’s complement of one’s complement sum of all 16 bit fields in the IP header (taking the checksum field to be zero for computation)

Version IHL Type of Service Total Length

Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address (32 bits) Source Address

Destination Address Options Padding see section 2.2.2 User data ...

Version IHL Type of Service Total Length Identification Flags Fragment Offset Destination Address (32 bits) Time to Live Protocol Header Checksum

Source Address Destination Address see section 2.2.2 Options Padding

User data ...

Version IHL Type of Service Total Length Options (variable length) Identification Flags Fragment Offset

Time to Live Protocol Header Checksum Source Address zero or more options Destination Address

Options Padding

User data ... Case 1: single octet option Case 2: option type (1 oct.) +option length (1 oct.) +option-data

Version IHL Type of Service Total Length Identification Flags Fragment Offset Padding Time to Live Protocol Header Checksum

Source Address Destination Address increases the IP header length to the next integer multiple of Options Padding User data ... 4 octets © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-25

IP Packet Header replace logo Options

Reference Model Usage is optional IP IP Packets Implementation is mandatory Addressing Fragementation ICMP Option Length ARP number of octets in (option-type + option-length + option-data) Routing Option Type UDP

bit:012 34567 CF OC Option Number

Copy Flag (CF): 1 = copy / 0 = do not copy (controls treatment of options under fragmentation) Option Class (OC): 0 = control 2 = debugging & measurement 1,3 = reserved for future use CF Copied Flag OC Option Class © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-26 IP Packet Header replace logo Options (2)

Reference Model Option Option IP Class Number Length Description IP Packets 0 0 – End of option list. Used for padding. Addressing No length octet. Fragementation 0 1 – No operation. No length octet. ICMP 0 2 11 Security and handling restrictions (US DoD) ARP 0 3 var. Loose source route. Request routing along Routing the specified routers. UDP 0 7 var. Record Route. Collect the addresses of routers along the path. 0 8 4 Strem identifier (SATNET, obsolete) 0 9 var. Strict source route. 0 11 4 MTU probe. Used for path MTU discovery. 0 12 4 MTU probe reply. Used for path MTU discovery. 0 20 4 Router alert. Request router to process end-to-end packet contents. (RFC2113) 2 4 var. Record timestamps along a route. 2 18 var. Traceroute. To find routers along a path.

DoD Department of Defense MTU Maximum Transmission Unit © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-27

Differentiated Services Field replace logo

Reference Model IP IP Packets Redefinition of the Type of Service (TOS) field in the IP Addressing header Fragementation ICMP 6-bit codepoints (DSCP) instead of Precedence, D, T and R ARP fields Routing no guarantee of service UDP local policy hint on how to handle packets dependent on hardware / local network capabilities

see Chapter 7

Reference Model IP Machines store data in different formats, even for integers IP Packets Little Endian: Addressing Fragementation Lowest memory address contains lowest-order byte of an ICMP integer. ARP Big Endian: Routing Lowest memory address contains highest-order byte of an UDP integer. plus: byte-swapping within 16 bit words

Standardized Network Byte Order Only a machine independent interpretation allows interworking!

IP, TCP and UDP: Transmit most significant byte first

extra issue for application protocols: transmission data formats must be defined individually

Example (1) replace logo

Reference Model IP datagram with only one octet of ICMP data IP IP Packets Addressing Fragementation 0 1 2 3 ICMP 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ARP Ver=4 IHL=5 TOS = 0 Total Length = 21 Routing Identification = 111 Flg=0 Fragment Offset = 0 UDP Time to Live = 8 Protocol = 1 Header Checksum Source Address = 192.168.3.2 Destination Address = 192.168.34.65 User data (8 bits)

Source: RFC791 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-30 Example (2) replace logo

TCP packet with four IP options set Reference Model 0 1 2 3 IP 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 IP Packets Addressing Ver=4 IHL=8 TOS = 0 Total Length = 576 Fragementation ICMP Identification = 111 Flg=0 Fragment Offset = 0 ARP Time to Live = 8 Protocol = 6 Header Checksum Routing Source Address = 192.168.3.2 UDP Destination Address = 192.168.34.65 Opt. Code = x Opt. Len. = 3 Option Value Opt. Code = x Opt. Len. = 4 Option Value Opt. Code = 1 Opt. Code = y Opt. Len. = 3 Option Value Opt. Code = 0 TCP data . . .

Source: RFC791 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-31

2.2.2 IP Addressing replace logo

Reference Model In communication from a source to a destination: IP IP Packets Addressing Fragementation Name ICMP identifies a resource (“identifier”) ARP independent of location of both source and destination Routing UDP Address tells where something is may depend on the location of the destination

Route tells how to get from a source to a destination depends on locations of source and destination (“go left, then take the third turn right”)

[Perlman 1999] © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-32 IP Address Parts replace logo

Reference Model . Network ID Host ID IP IP Packets Addressing Fragementation 32 bit IP address is divided into Network ID and Host ID ICMP Network ID ARP first part of the IP address Routing used for routing packets towards a network UDP must be known by every Internet router routers ignore the host ID part of the address when looking up the next hop routing is the same for all hosts with the same network ID Host ID identifies a host within an IP network all hosts on the same network have the same network ID communication within one network uses lower layer mechanisms to deliver packets e.g. Ethernet and ARP

IP Addresses / Historical replace logo

Reference Model Classful Internet Addresses (original scheme) IP bit 0311234 81624 IP Packets Addressing Class A: Fragementation 0 Network ID Host ID ICMP ARP Class B: Routing UDP 1 0 Network ID Host ID

Class C: 1 1 0 Network ID Host ID

Class D: 1 1 1 0 Multicast Address

Class E: 1 1 1 1 reserved (for future use)

Reference Model 32bit IP address specifies IP IP Packets a network (Network ID) Addressing a host on this network (Host ID) Fragementation ICMP ARP optimized for fast extraction of Network ID part Routing hosts attached to multiple networks (e.g. routers) UDP must have separate IP addresses at each interface

network address all Host ID bits = 0 Zero means “this” network 0.0.0.0 = “this network” useful during initialization phases when actual Network ID is not known yet One means “all” broadcast addresses

Special IP Addresses replace logo

Reference Model 0 means “this” and 1 means “all” IP IP Packets Addressing all 0 This host Fragementation startup only source only ICMP ARP Network ID = all 0 Host ID Host on this net Routing startup only UDP source only

all 1 Limited (local net) broadcast destination only

Network ID Host ID = all 1 Directed broadcast to net destination only

127 any Host ID (mostly 0.0.1) Loopback never on real network

variable-length prefix interpreted in local networks Reference Model IP host part of wide-area address is further subdivided IP Packets determined by subnetwork mask Addressing Fragementation example: ICMP “Class B” ARP 1 0 Network ID Host ID Routing UDP Subnet mask 23x”1” 9x”0” effective Network ID (21 bit) Host ID (9 bit)

used in local network Network ID Host ID wide area network routes according to classful address 1 0 Network ID not considered for routing

Classless Addressing replace logo “Supernetting”

basically like subnetting, but Reference Model also used in WAN IP IP Packets also to reduce network mask Addressing reasons: Fragementation only 16384 class B networks ICMP -> “ROADS” (running out of address space) problem ARP only few of the ~2 million class C networks are really assigned Routing UDP combine e.g. multiple class C networks into a larger network only one common routing entry in wide area network routers additional prefix lengthto be stored and used for routing

“Classless Inter-Domain Routing” (CIDR) [RFC1518, RFC1519] specify prefix length along with network address (number of “1” bits in network mask) knowledge of prefix for each network address required by all WAN routers work-around (historical, expensive!): insert many routes to classful network addresses

CIDR notation (“slash notation”) Reference Model network address /mask length IP e.g. 192.168.10.0 /28 IP Packets Addressing or: 192.168 /16 Fragementation power of two number of addresses per address block ICMP ARP route lookup is more complicated (see later) Routing Prefix Length network mask (hex) network mask (dotted) number of hosts in network 30 ff ff ff fc 255.255.255.252 2 UDP 29 ff ff ff f8 255.255.255.248 6 28 ff ff ff f0 255.255.255.240 14 27 ff ff ff e0 255.255.255.224 30 26 ff ff ff c0 255.255.255.192 62 25 ff ff ff 80 255.255.255.128 126 24 ff ff ff 00 255.255.255.0 254 23 ff ff fe 00 255.255.254.0 510 22 ff ff fc 00 255.255.252.0 1022 21 ff ff f8 00 255.255.248.0 2046 20 ff ff f0 00 255.255.240.0 4094 19 ff ff e0 00 255.255.224.0 8190 18 ff ff c0 00 255.255.192.0 16382 17 ff ff 80 00 255.255.128.0 32766 16 ff ff 00 00 255.255.0.0 65534 ...... © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-39

IP Address versus Link Layer Address replace logo

Reference Model Address IP provides a unique identification of an end system IP Packets Addressing contains information how to reach the element Fragementation ICMP Link Layer Address (LAN Address, MAC Address) ARP worldwide unique Routing no topological structure UDP no information as to where the element is located rather a name than an address

Network Layer Address (IP Address) worldwide unique (at least within the Internet) structured (network + host part) network address indicates location of end system

Reference Model Classful addresses IP IP Packets host IP Addr. Class Network Addr. Broadcast Addr. Addressing Fragementation 203.24.8.3 C 203.24.8.0 203.24.8.255 ICMP 23.1.0.4 A 23.0.0.0 23.255.255.255 ARP 129.69.170.1 B 129.69.0.0 129.69.255.255 Routing UDP Classless addresses host IP Addr. Netmask Netw. Addr. Broadcast Addr. 203.78.5.34 0xffffff00 203.78.5.0 203.78.5.255 (203.78.5.0 /24) 203.78.5.34 0xfffffc00 203.78.4.0 203.78.7.255 (203.78.4.0 /22) 203.78.5.34 0xffffffe0 203.78.5.32 203.78.5.63 (203.78.5.32 /27)

Special Networks replace logo

Local (Loop) Network interface nly!! Reference Model inteerrnnaalluusseeoonly 127.0.0.0 ffoorrhhoosstt int IP IP Packets localhost is always at 127.0.0.1 Addressing Fragementation Default (local) network ICMP 0.0.0.0 ARP Routing Private network addresses [RFC 1918] UDP reserved for private use will not be routed in the wide area

Network Prefix Lowest Highest Address Length Host Address Host Address 10.0.0.0 8 10.0.0.1 10.255.255.254 172.16.0.0 12 172.16.0.0 172.31.255.254 192.168.0.0 16 192.168.0.1 192.168.255.254 169.254.0.0 16 169.254.0.1 169.254.255.254 (169.254.0.0/16 used for IP address autoconfiguration)

Physical network (e.g. Ethernet LAN) treats an IP datagram Reference Model as “user data” IP IP Packets IP datagram Addressing Fragementation ICMP IP datagram header IP datagram user data ARP Routing Frame FCS UDP header LAN user data

LAN Frame

Maximum payload size in frame determines maximum size of IP datagram “Maximum Transfer Unit”, MTU e.g. Ethernet: 1500 octets IEEE 803.2 / SNAP: 1492 octets FDDI: approx. 4470 octets ... © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-43

Fragmentation (2) replace logo

Reference Model IP IP Packets MTU can change from hop to hop Addressing Fragementation ICMP ARP Network 3 Network 1 Routing MTU=1500 UDP MTU=1500 R2

R Network 2 1 MTU=620

R1 cannot forward 1500 octet IP datagrams into network 2

Reference Model Choice of two alternatives: IP IP Packets a) introduce extra link-by-link segmentation and reassembly Addressing Fragementation (SAR) protocol ICMP IP would only run on links that provide SAR ARP Routing b) make IP adapt to the next hop’s MTU UDP IP fragmentation reassembly at destination due to the connectionless nature of IP fragments are again valid IP packets IP can run on any link layer minimum necessary MTU for an 8 octet transfer - with minimum IP header only: 28 octets - including minimum TCP header: 48 octets reasonable minimum required MTU around 100 octets to limit overhead

Fragmentation (4) replace logo

Reference Model Original IP Datagram IP IP Packets Addressing IP Header IP User Data Fragementation ICMP ARP Fragments MTU Routing UDP FH IP Header IP User Data MTU

FH IP Header IP User Data

Multiple fragmentation is possible Fragments can have different sizes

FH Frame Header © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-46 Fragmentation (5) replace logo

Reference Model Each fragment includes an IP header IP IP Packets datagram ID copied Addressing options copied only if “copy” flag is set to 1 Fragementation ICMP ARP maximum size of data part in fragments:

Routing LFD = MTU - LIH UDP number of fragments = − nF (LD LIH ) / LFD

LD Datagram Length LFD Data part Length in Fragment LIH IP Header Length MTU Maximum Transfer Unit

nF Number of Fragments

Fragmentation (6) replace logo

Version IHL Type of Service Total Length

Identification Flags Fragment Offset Reference Model Time to Live Protocol Header Checksum Source Address

Destination Address IP Options Padding IP Packets Fragment offset User data ... Addressing given as 8 octet (64 bit) count in the IP header Fragementation indicates position of first octet of IP data field in the original ICMP datagram ARP MF (more fragments) flag indicates last fragment Routing UDP Example: 1420 octets datagram, MTU=620

IP Header IP User Data, 1400 octets

IP Header IP User Data, 600 octets MF=1 FO=0 data offset=0

IP Header IP User Data, 600 octets MF=1 FO=75 data offset=600

IP Header Data, 200 oct. MF=0 FO=150 data offset=1200

FO Fragment Offset MF More Fragments © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-48 Fragmentation (7) replace logo

Reference Model IP IP Packets Datagram ID used to collect fragments for reassembly Addressing Fragementation ICMP Total Length field in IP header gives length of fragment, ARP not of the original datagram Routing original datagram length only known after reception of the last UDP fragment (MF flag = 0) receiver needs to reserve large reassembly buffer

Don’t Fragment flag in IP header fragmentation not allowed router will send ICMP message back to sender (see sec. 2.3) can be used to test maximum possible datagram size used to avoid having the receiver reassemble a datagram

Chapter 2: Network Layer (et al.) replace logo

Reference Model IP Internet Control Message Protocol ICMP ARP Companion protocol to IP Routing required in every IP implementation (“part of IP”) UDP uses IP datagrams for transport protocol number 1 Used to report problems with IP datagram delivery Error reporting only message goes back to datagram’s source IP address application in end system can make use of the notification no error correction No error reports generated for ICMP packets avoid network congestion due to error message avalanches

ICMP Messages replace logo

Reference Model IP general message format: ICMP 4 octets common part ARP further information depends on message type Routing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 UDP Type Code Checksum

further information . . .

same checksum algorithm as for IP datagrams only covers the ICMP message type field defines meaning and format of ICMP message error reports include first 64 bits of original datagram allow end system to attribute message to application program

Reference Model 0 Echo Reply IP 3 Destination Unreachable ICMP 4 Source Quench ARP 5 Redirect (change a route) Routing UDP 8 Echo Request 9 Router Advertisement 10 Router Solicitation 11 Time exceeded for a datagram 12 Parameter problem on a datagram 13 Timestamp Request 14 Timestamp Reply 15 Information Request (obsolete) 16 Information Reply (obsolete) 17 Address Mask Request 18 Address Mask Reply

Reachability Test replace logo

Reference Model uses ICMP echo request and echo reply IP receiver of echo request returns echo reply message ICMP optional data copied from echo request ARP Routing corresponding tool: “ping” UDP transmit ICMP echo request wait for corresponding echo reply with matching identifier and sequence number

0 8 16 31 Type (8 / 0) Code (0) Checksum Identifier Sequence Number

Optional data . . .

Router cannot forward packet Reference Model IP destination host cannot accept packet ICMP 0 8 16 31 ARP Type (3) Code (0–12) Checksum Routing Unused (must be zero) UDP IP header + first 64 bits of datagram . . . Codes 0 Network unreachable 8 Source host isolated 1 Host unreachable 9 Communication with destination 2 Protocol unreachable network administratively prohibited 3 Port unreachable 10 Communication with destination 4 Fragmentation needed host administratively prohibited and DF set 11 Network unreachable 5 Source route failed for Type of Service 6 Destination network unknown 12 Host unreachable 7 Destination host unknown for Type of Service © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-55

Route Change replace logo

Reference Model Routers are assumed to know a correct route to the IP destination ICMP ARP hosts have minimal routing information Routing can be started up knowing only one router UDP may learn additional information from routers

0 8 16 31 Type (5) Code (0–3) Checksum Router Internet Address IP header + first 64 bits of datagram . . .

Codes: 0 Redirect datagrams for the Net (now obsolete) 1 Redirect datagrams for the Host 2 Redirect datagrams for the Type of Service and Net 3 Redirect datagrams for the Type of Service and Host

Reference Model IP Due to routing table inconsistencies, packets can take loops ICMP in a connectionless network ARP loop detection needed Routing UDP Use IP header TTL (Time to Live) field decrement TTL when forwarding a packet discard packet when TTL reaches zero

0 8 16 31 Type (11) Code (0–1) Checksum Unused (must be zero) IP header + first 64 bits of datagram . . .

Codes: 0 TTL exceeded 1 Reassembly time exceeded

Parameter Problem replace logo

Reference Model IP Problem with IP header ICMP e.g. wrong option parameters ARP only if datagram has to be discarded Routing Pointer to problematic header octet helps identify the UDP problem

0 8 16 31 Type (12) Code (0–1) Checksum Pointer Unused (must be zero) IP header + first 64 bits of datagram . . .

Codes: 0 Parameter problem, pointed to by Pointer field 1 Required IP header option is missing, e.g. security in secure environment

Reference Model IP Used to request the local address mask from a router ICMP broadcast if no router is known ARP Routing router replies to the request UDP 0 8 16 31 Type (17 / 18) Code (0) Checksum Identifier Sequence Number Address Mask (reply)

Router Advertisement replace logo

Sent periodically by routers Reference Model soft state, i.e. state is only kept for a given lifetime IP 0 8 16 31 ICMP ARP Type (9) Code (0) Checksum Routing Num Addrs Addr Size (1) Lifetime UDP Router Address 1 Preference Level 1 Router Address 2 Preference Level 2 . . .

Num Addrs = number of entries in data part Addr Size = size of address entries in 32 bit words (IPv4: 1; IPv6: 4) Lifetime = life time in seconds for this advertisement default: 30 min (1800s), periodic transmission every 10 min (600s) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-60 Router Solicitation replace logo

Reference Model IP Ask available routers to send an advertisement immediately ICMP used by freshly booted hosts ARP send to broadcast address (255.255.255.255) Routing or to the “all routers” multicast address (224.0.0.2) UDP

0 8 16 31 Type (10) Code (0) Checksum Reserved

Chapter 2: Network Layer (et al.) replace logo

Reference Model IP Link Layer (local / hardware) addresses are used in all local ICMP communications ARP e.g. MAC addresses in Ethernet LAN Routing UDP Source host wants to send a packet to destination only receiver’s IP address is known mechanism needed to find out hardware address “Address Resolution Problem”

ARP (Address Resolution Protocol) used to discover local (“hardware”) address for a given IP address on the local network

Address Resolution Protocol replace logo Example

Reference Model Example local network IP ICMP A wants to transmit a datagram ARP C F B to host with IP addess IPB Routing UDP A G D E A transmits an ARP broadcast to all hosts on local network, including its own IP and hardware addresses

B updates its ARP cache with C F B A’s data B sends reply back to A A G D E using A’s hardware address A updates its ARP cache with B’s data

Reference Model Local network packets, not belonging to the IP layer IP 0 8 16 31 ICMP Hardware Type Protocol Type ARP Routing HLEN PLEN Operation UDP Sender HA (octets 0–3) Sender HA (octets 4–5) Sender IP (octets 0–1) Sender IP (octets 3–4) Target HA (octets 0–1) Target HA (octets 2–5) Target IP

Protocol Type: 080016 = IPv4 Operation: 1 ARP Request 2 ARP Response ARP Address Resolution Protocol HA Hardware Address 3 RARP Request HLEN HA Length 4 RARP Response PLEN Protocol Address Length RARP Reverse ARP © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-65

RARP replace logo

Reference Model IP Reverse Address Resolution Protocol ICMP ARP Routing Used at host startup UDP e.g. for diskless hosts requires RARP server(s) determine host IP from hardware address

request sent to broadcast hardware address reply sent to sender’s hardware address rather than “Target HA”

RARP Ethertype = 803516

ARP Ethertype = 080616

Reference Model Example local network IP ICMP A is booted ARP C F B Routing A transmits a RARP broadcast UDP to all hosts on local network A G D E

C F B RARP servers C and E recognize HAA and send a reply to A including IPA A G D E

Chapter 2: Network Layer (et al.) replace logo

Reference Model How to deliver a datagram? IP To a destination on the local network: ICMP send the datagram directly ARP use e.g. ARP to obtain corresponding hardware address Routing Principle To other destinations: Algorithms Protocols send the datagram via routers UDP Example Network Host A directly connected to N 1 B, C, D, E, F, G, R1, R2 to network N1 C R F B 1 route via R1 to network N2

A G D E R2 route via R2

Routing Table replace logo

Reference Model Basic organisation of a routing table: IP per entry: destination_networkdestination_network next_hop_addressnext_hop_address ICMP ARP Routing all “next hops” must be on the same physical network as Principle Algorithms the router under consideration Protocols UDP default route for all other destination networks networks need not be listed separately in the routing table useful when most of the Internet is reached via one router

additional host routes to individual hosts are possible

“information hiding” list only as much information as necessary for a real example, see slide 2-80

Reference Model IP Network N3 Network ICMP 201.8.25.0/24 N1 207.1.221.0/24 ARP 201.8.25.254 Routing R Principle 1 213.5.6.253 Algorithms C F B Protocols Network UDP 213.5.6.254 213.5.6.0/24

A G D E R2 133.54.6.253 Network N2 133.54.0.0/16 Rest of the world HostHost routingrouting tablestables forfor hostshosts A–GA–G default route defaultdefault 213.5.6.254 213.5.6.254 201.8.25.0/24201.8.25.0/24 213.5.6.253 213.5.6.253 route to class C netw. 201.8.25.0 207.1.221.0/24207.1.221.0/24 213.5.6.253 213.5.6.253 route to class C netw. 207.1.221.0

Routing Algorithm replace logo

Reference Model Extract destination IP address IP from datagram and IP D ICMP compute network prefix N ARP Routing if N matches any directly connected network address Principle deliver datagram to destination IP over that network Algorithms D Protocols (resolve IPD to a physical address, encapsulate datagram, UDP send frame)

else if the table contains a host-specific route for IPD send datagram to next hop specified in routing table else if the table contains a route for network N send datagram to next hop specified in routing table else if the table contains a default route send datagram to the default router specified in the routing table else report a routing error

Reference Model IP get next hop from routing table ICMP get hardware address for next hop (ARP / ARP cache) ARP Routing reduce Time To Live (usually by 1) Principle recompute header checksum Algorithms Protocols send datagram on local network UDP to the next hop’s hardware address address fields in IP header are not modified! (exception: source routing option fields)

Hosts and Routers replace logo

Reference Model IP Router ICMP receives datagrams on all physical networks ARP looks up in routing table to forward datagrams to their next hops or Routing Principle forward datagrams to their destination Algorithms should know about all locally available routers Protocols talks to other routers (“routing protocol”) UDP (and can be addressed itself)

Host receives datagrams sends out datagrams according to routing table to destination if local to next hop router if non-local can live with knowing just one router “multi-homed” host can have multiple network addresses be careful when forwarding packets (avoid routing loops!)

Reference Model Include subnet mask in routing table IP ICMP SubnetSubnet MaskMask Network Network AddressAddress Next Next HopHop ARP Routing Principle check if 32bit AND of destination address and network mask in Algorithms routing table entry is equal to network address in routing table Protocols entry UDP next hop still needs to be accessible on the local network

Beware of ambiguities! Use consistent subnet masks across all networks within the same subnetted IP network otherwise subnet broadcasting is ambiguous use contiguous bits to form subnet masks hosts can obtain local subnet maks from router via ICMP

Subnet Routing replace logo Algorithm

Reference Model extract destination IP address IPD from datagram IP ICMP ARP if prefix of IPD matches any of the locally connected networks Routing forward packet to destination host via corresponding local network Principle Algorithms else Protocols for each routing table entry UDP N = bitwise AND of IPD and subnet mask if N = network address of entry route datagram to corresponding next hop end of “for” loop

if no matches were found if there is a default route send datagram to corresponding next hop else report a routing error

Reference Model Used for point-to-point links IP no prefix/suffix assignment ICMP ARP avoid numbering of leased lines Routing host interfaces at the ends do not have IP addresses Principle Algorithms no addressing on point-to-point link (see chapter 5) Protocols arbitrary value can be used as next-hop address UDP Example 201.8.25.254 207.1.221.253

N Leased serial line N Network 1 R1 R2 2 12no IP addresses 1 2 207.1.221.0 Network 201.8.25.0 Routing Table for R 1 NetworkNetwork Next Next HopHop Interface Interface y 201.8.25.0201.8.25.0 direct direct 1 1 man rreeaaddaabbiilliitty JuJussttffoorr hhuuman 207.1.221.0207.1.221.0 207.1.221.253 207.1.221.253 2 2

CIDR Routing replace logo

Reference Model IP this is the standard today ICMP Instead of one route per classful network address, routing ARP tables contain network address and prefix length Routing CIDR notation, e.g. “129.211.168.0 / 21” Principle Algorithms Protocols UDP classless addresses are not self-identifying longest prefix match determines route inefficient to search through all table entries hashing does not work well

use e.g. Binary Trie structures to store and look up routes level compressed trie routing lookup realized in hardware on today’s routers

Reference Model IP How is a routing table built? ICMP Use routing algorithms (2.5.2) Routing datagrams ARP communicate via protocol to be routed Routing routing protocols (2.5.3) Principle Algorithms Protocols Routing Protocols and algorithms UDP Algorithm are coupled Table updates Routing Forwarding Table Engine

send datagram to next hop (physical address)

Routing Table Example replace logo

#show ip rout

Protocol/Route type codes: I1- ISIS level 1, I2- ISIS level2, I- route type intra, IA- route type inter, E- route type external, i- metric type internal, e- metric type external, O- OSPF, E1- external type 1, E2- external type2, N1- NSSA external type1, N2- NSSA external type2

Prefix/Length Type Next Hop Dist/Met Intf ------10.7.0.0/29 O-I 10.7.0.9 110/6 FastEthernet1/7 10.7.0.8/29 Connect 10.7.0.10 0/0 FastEthernet1/7 10.7.0.16/29 O-I 10.7.0.9 110/2 FastEthernet1/7 10.7.0.24/29 Connect 10.7.0.25 0/0 FastEthernet1/5 10.7.0.32/29 Connect 10.7.0.33 0/0 FastEthernet1/6

Reference Model IP For a given topology, find out the shortest path to each ICMP destination. ARP Routing Principle Algorithms Challenges Protocols avoid loops UDP react to failures react to topology changes discover topology

Distance Vector Algorithms Link State Algorithms

Distance Vector Routing replace logo

Reference Model IP Also known as Bellman-Ford algorithm ICMP ARP Principle: keep a list of all known routes in a table Routing per entry: destination and distance (e.g. number of hops) Principle Algorithms Protocols initialize table with directly connected networks UDP send routing table periodically to all other routers reached directly “distance vector”: pairs of (destination, distance) elements receiver updates its table add new destinations modify next hop if necessary (add one hop to advertised distances!)

Reference Model IP Initialisation ICMP ARP DestinationDestination Distance Distance Next Next HopHop N1 R1 N2 Routing NN11 0direct0direct Principle NN22 0direct0direct Algorithms Protocols UDP some time later Update from R4

Dest.Dest. Dist. Dist. Next Next HopHop Dest.Dest. Dist. Dist.

NN11 0direct0direct NN11 22 N 0direct N 3 N22 0direct N44 3 New next hop NN44 8R8R22 NN77 66 NN77 5R5R33 NN88 55 N 6R N 3 N88 6R44 N99 3 New destination NN1010 2R2R55 NN1010 99 N 2R N 4 N1212 2R44 N1212 4 Update distance

Distance Vector Routing replace logo Properties

Reference Model easy to implement IP extra loop prevention mechanisms may be needed ICMP ARP large message exchanged Routing slow convergence after route changes Principle Algorithms incorrect information can cause loss of connectivity or routing Protocols loops UDP “count to infinity problem” -> low maximum allowed distance needed Example

R1 R2 R3 N1

after loss of connection between R3 and N1

R1 R2 R3 N1

Reference Model IP Also known as “shortest path first” (SPF) ICMP ARP Routing Each router has complete topology information Principle graph Algorithms Protocols nodes = routers UDP edges = links (only if two routers can communicate directly) interface cost and link cost metrics

Router actions actively test status of all direct links (with tolerance: k out of n HELLO packets must be received) distribute link status information to all other routers (broadcast) compute new shortest paths using Dijkstra’s Shortest Path algorithm on the graph

2.5.3 Routing Protocols replace logo

Reference Model IP Routing protocols used to ICMP discover routes ARP propagate route information Routing validate routes Principle Algorithms check route consistency Protocols UDP Autonomous System (AS) group of networks and routers controlled by a single administrative authority hidden networks advertised to other AS central assignment of AS numbers

each AS can choose a different routing protocol

Reference Model IP Communication between different Autonomous Systems ICMP exterior gateway protocols (EGP) ARP propagation of reachability information Routing routing metrics are not communicated or interpreted Principle Algorithms internal structures are hidden Protocols UDP Communication within Autonomous Systems interior gateway protocols (IGP) propagation of reachability information propagation of routing metrics (distance, cost, etc) optimisation possible using internal structure information Exterior IGP 1 gateway used protocol IGP 2 AS1 R1 R2 AS2 used

Protocol Overview replace logo

Reference Model IP Exterior Gateway Protocols ICMP Border Gateway Protocol (BGP), currently BGP-4 ARP Routing Principle Interior Gateway Protocols Algorithms Protocols OSPF (Open Shortest Path First) IS-IS (from OSI standards) UDP IGRP RIP (Routing Information Protocol)

IS Intermediate System © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-88 BGP replace logo

an exterior gateway protocol Reference Model IP coordinates information released from different BGP routers ICMP within the same AS ARP propagates reachability information Routing Principle supplies next-hop information Algorithms Protocols mixture between distance-vector and link state protocol UDP policy can hide selected parts of an AS runs over TCP (reliable transport!) communicates changes as incremental updates supports CIDR supports route aggregation supports authentication (sender of messages can be verified) AS Autonomous System BGP Border Gateway Protocol implemented in Unix gated CIDR Classless Inter Domain Routing TCP Transmission Control Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-89

BGP (2) replace logo

Reference Model Message Types IP Open initialize communication ICMP Update advertise or withdraw routes ARP Routing Notification response to an incorrect message Principle Algorithms Keepalive actively test peer connectivity Protocols UDP Marker in message header allows message delineation from octet stream delivered by TCP

additional configuration needed in case of multiple interconnections routing arbiter system: one route server running BGP

metric transformation allows interworking with IGPs routes between hosts in the same AS should not leave the AS © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-90 RIP replace logo

Reference Model IP an interior gateway protocol ICMP ARP (implemented by Unix routed) Routing distance-vector protocol Principle Algorithms no explicit loop detection Protocols low value (16) for maximum possible distance UDP “count to infinity” problem after loss of connectivity

OSPF replace logo

Link state protocol Reference Model each router computes next hops via shortest path routing IP algorithm (Dijkstra) ICMP link state is supervised using HELLO messages ARP (aggregated) link state updates are flooded through the network Routing support for host specific, subnet specific and classless routes Principle load balancing support (alternative routes) in ECMP mode Algorithms (equal cost multi path) Protocols further properties UDP Open specification without license fees (-> “open” SPF) one route per IP Type of Service possible partitioning of networks into “areas” authenticated information exchange possible support for hardware broadcast capability support for abstract virtual network topology Message types Hello (test reachability) Database description (topology) Link status request Link status update Link status acknowledgement © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-92 Chapter 2: Network Layer (et al.) replace logo

2.6 UDP replace logo

Reference Model IP User Datagram Protocol ICMP ARP IP protocol number 17 Routing offers an interface to send IP packets UDP unreliable connectionless datagram service uses IP additional address (“port number”) to distinguish between different communication relations low additional complexity and overhead to IP higher layer protocol needed to deal with packet loss packet re-ordering packet duplication loss of connectivity

Reference Model IP UDP header and packet format ICMP ARP 0 8 16 31 Routing UDP Source Port UDP Destination Port UDP UDP Message Length UDP Checksum Data . . .

source port, destination port: 16 bit numbers source port is optional (0 if unused) reference allowing to reply to a packet length: number of octets in UDP header and data fields (minimum: 8)

UDP replace logo Format (2)

Reference Model IP Checksum ICMP optional (0 if not used) ARP also secures data field (in contrast to IP checksum) Routing same algorithm as for IP header (one’s complement sum) UDP use “11...1” representation of zero if result is zero (to distinguish from “not used” option) computation includes “pseudo header”

Reference Model Additional values used to compute the UDP checksum IP source and destination IP addresses ICMP protocol number ARP UDP datagram length (without pseudo header) Routing to check correct destination UDP not transmitted, but values obtained from IP module 0 8 16 31 Source IP Address Destination IP Address Zero Protocol UDP Length UDP Source Port UDP Destination Port UDP Message Length UDP Checksum

Data . . .

Padding (zero) Padding to n x 16bit

UDP PDU (transmitted) UDP Pseudo Header (obtained from IP layer) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-97

Well known UDP port numbers replace logo

Reference Model Port (dec.) keyword description IP 0–reserved ICMP 7 echo echo what is received ARP 9 discard discard all received information Routing 13 daytime answer with date and time 19 chargen character generator UDP 53 domain Domain Name Server (DNS) 67 bootps bootp or DHCP server 68 bootpc bootp or DHCP client 69 tftp trivial file transfer protocol 88 kerberos Kerberos security service 111 Sun rpc Sun remote procedure call (portmapper) 123 ntp Network Time Protocol 161 snmp Simple Network Management Protocol 162 snmp-trap SNMP trap (active notifications) many services blocked due to security concerns longer list: see RFC1700

2.1 What routes are configured in your end system? Reference Model 2.2 How many networks does University of Stuttgart use? How many IP Class B networks? ICMP 2.3 How many internet domains (third-level)? ARP Routing 2.4 Why can reassembly only be done at the final destination? UDP 2.5 Examine the routing tables of hosts you have access to (Hint: Use the “route“ or “netstat” tools) Questions 2.6 How does the “traceroute” program work? 2.7 Modify the routing algorithm (2-71) to include source routing 2.8 Which ICMP messages does a router generate?

2.9 Devise a simple protocol to recover from packet loss. 2.10 What would you describe as fairness? 2.11 Test the throughput on your local network with n parallel TCP connections (n=1,2,3,4) 2.12 Test the throughput on the Internet with n parallel TCP connections. © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 2 Edition Summer 2004 2-99 replace logo INFOTECH Lecture

Information and Communication Networks

IP Based Networks and Applications Chapter 3: Transport Layer

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Transport Layer information is only evaluated by end systems connection state is only present in end systems exceptions: Layer 4 switching, etc

IP routers just forward packets connectionless packet switching “best effort” delivery

Transport protocols can provide reliable service

Internet Speciality: Transport Layer instead of Network Layer is responsible for congestion control / overload control compliance problem!

Chapter 3: Transport Layer replace logo

TCP 3.1 TCP (Transmission Control Protocol) Congestion Control 3.1.1 Overview Assigned Numbers 3.1.2 Reliable Transport Other T. Protocols 3.1.3 TCP Header 3.1.4 Reliable Transport in TCP 3.1.5 Connection Concept 3.2 TCP Flow and Congestion Control 3.2.1 Principle 3.2.2 Congestion Control Algorithms: Tahoe, Reno, Vegas 3.2.3 TCP Performance 3.2.4 Extensions 3.3 Assigned Numbers 3.4 Other Transport Protocols 3.4.1 SCTP 3.4.2 RTP

TCP Overview Reliable Transp. Transmission Control Protocol TCP Header Reliable Transp. in TCP Connections specified in RFC793 (Sep. 1981) Congestion Control clarified in RFC 1122 (Oct. 1989) Assigned Numbers Other T. Protocols Some additions: Extensions for long delay [RFC 1072] Big Windows [RFC1106, RFC1110] Selective Acknowledgement [RFC 2018] Increasing TCP’s Initial Window [RFC 2414] NewReno Fast Recovery [RFC 2582]

3.1.1 Overview replace logo

TCP Stream oriented transport protocol Overview user data taken as octet (byte) stream Reliable Transp. TCP Header delivered in the same octet sequence Reliable Transp. in TCP Virtual Circuit Connection Connections builds connection oriented service above connectionless layer Congestion Control (IP) Assigned Numbers Buffered Transfer Other T. Protocols TCP can collect user data from multiple user calls into one packet increased efficiency (less TCP/IP overhead per user data octet) “push”: deliver the data now (not necessarily as a single packet!) Unstructured Stream application programs must define and parse stream formats Full Duplex Connection no need for opening a separate reverse connection piggy-backing of protocol control information

Open TCP Overview active: open a connection to a communication partner Reliable Transp. passive: be ready to accept connections from a communication TCP Header Reliable Transp. partner in TCP Connections Close Congestion Control transmit remaining data, then close the connection Assigned Numbers Send Other T. Protocols submit data to transmit unstructured octet stream “push” if no more data are to come (e.g. when waiting for partner’s application layer protocol to answer) Receive accept received data from network Status check connection status Abort

3.1.2 Reliable Transport replace logo

TCP Overview Reliable Transp. Basis: unreliable connectionless Network Layer TCP Header Reliable Transp. protect against in TCP Connections lost packets Congestion Control duplicated packets Assigned Numbers out-of-order delivery of packets Other T. Protocols

Positive Acknowledgements receiver sends ACK in backward direction requires duplex connection Retransmissions sender starts timer after transmission repeat packet if no ACK received after timeout

[remember: negative ACKs are not generally possible]

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 3 Edition Summer 2004 3-8 Reliable Transport replace logo Positive Acknowledgments, Retransmission Timer

TCP Overview Sender Receiver Reliable Transp. TCP Header Data Packet #1 Reliable Transp. Set Timer in TCP Reset Timer ACK #1 Connections Data Packet #2 Congestion Control Set Timer Assigned Numbers Reset Timer ACK #2 Other T. Protocols Data Packet #3 Set Timer Reset Timer ACK #3 Time

Choice of Timer value long enough to allow for network and host delays short enough to ensure fast reaction to packet loss

Reliable Transport replace logo Packet Loss

TCP Sender Receiver Overview Reliable Transp. Data Packet #2 TCP Header Set Timer Reliable Transp. Packet in TCP Loss Connections Timer expires Congestion Control Data Packet #2 Assigned Numbers Set Timer ACK #2 Other T. Protocols Reset Timer Data Packet #3 Set Timer ACK #3 CK DDaattaa aanndd AACK be lloosstt!! Timer expires ppaacckkeettss ccaann be Data Packet #3 Set Timer Reset Timer ACK #3 Time

TCP One data packet per round-trip time Overview one-bit sequence numbers are sufficient Reliable Transp. TCP Header “alternating bit protocol” Reliable Transp. in TCP Connections Data Packet #1 Congestion Control ACK #1 Assigned Numbers Data Packet #2 Other T. Protocols ACK #2 Time

Idea: Allow more packets per RTT decrease idle time

Data Packet #1 Data Packet #2 ACK #1 ACK #2 Data Packet #3 Time

Transmission Window (2) replace logo

TCP Overview Larger transmission window Reliable Transp. transmit more packets until TCP Header acknowledgement is needed Reliable Transp. in TCP “sliding window” Connections line speed can be reached Congestion Control longer sequence numbers Assigned Numbers needed to avoid ambiguity Other T. Protocols more packets to repeat after loss

Data Packet #1 Data Packet #2 Data Packet #3 ACK#1 Data Packet #4 ACK#2 Data Packet #5 ACK#3 Time

TCP Overview Bit positions: Reliable Transp. 0 1 2 3 TCP Header Reliable Transp. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 in TCP Connections Source Port Destination Port Congestion Control Sequence Number Assigned Numbers Acknowledgement Number* Other T. Protocols HLEN reserved Window* FIN RST PSH SYN ACK URG Checksum Urgent Pointer Options Padding

User data ...

* Field refers to data transmission in reverse direction (piggy-backed)

Source: RFC793 (September 1981) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 3 Edition Summer 2004 3-13

TCP Header replace logo Fields

TCP Overview Reliable Transp. Source Port (16 bits) TCP Header Reliable Transp. Destination Port (16 bits) in TCP TCP layer “addresses” Connections 0 reserved Congestion Control 1–1023: privileged Assigned Numbers used to be equivalent to “trusted” in times when Other T. Protocols root access to machines was supposed to be well controlled Client-Server communication: client program allocates a port (usually above 1023) server contacted at well-known port (see Section 3.3) connection identification by 5-tuple two IP addresses, protocol number, two port numbers

TCP Overview Sequence Number (32 bits) Reliable Transp. TCP Header initialized (“synchronized”) at connection set-up Reliable Transp. associated with transmitted octet, not packet in TCP allows different packetization for retransmission Connections number of the first data octet transmitted in the segment Congestion Control exception: connection set-up (SYN) gives Initial Sequence Number Assigned Numbers (ISN), Other T. Protocols first data packet has number ISN+1 32-bit number unique during lifetime of corresponding packet sufficient for 4GB e.g. 32s at 1Gbit/s

Acknowledgement Number (32 bits) gives number of next octet expected refers to reverse direction data flow (“piggy-backing”) RFC 793: “Acknowledgment”

TCP Header replace logo Fields (3)

TCP Overview Reliable Transp. HLEN (4 bits) TCP Header Reliable Transp. length of the TCP header (without IP) in 32bit words in TCP indicates position of first data octet in 32bit words Connections RFC793: “data offset” Congestion Control TCP header length is always an integer of 32 bit Assigned Numbers Other T. Protocols Reserved (6 bits) reserved for future use must be zero

TCP Overview Reliable Transp. Control Bits (6 bits) TCP Header Reliable Transp. bit = 1 means in TCP URG “Urgent Pointer” field is valid Connections ACK “Acknowledgement Number” field is significant Congestion Control PSH user process requested a “push” Assigned Numbers RST Reset (abort) the connection Other T. Protocols SYN Synchronize sequence numbers (set-up connection) FIN No more data from sender (close connection)

Window (16 bits) number of octets the sender of this segment is willing to accept starting at octet number “Acknowledgment Number” field refers to reverse direction data flow (“piggy-backing”)

TCP Header replace logo Fields (5)

TCP Overview Reliable Transp. Checksum (16 bits) TCP Header Reliable Transp. one’s complement of 16bit one’s complement sum of in TCP TCP header Connections user data Congestion Control TCP pseudo header prepended Assigned Numbers “zero” octet appended if needed to make the whole segment have an integer number of 16bit words Other T. Protocols Pseudo header: 0 8 16 31 Source IP Address Destination IP Address Zero Protocol TCP Length

created from information received in the IP header secures important information to identify a connection TCP Length = number of octets in TCP header plus data without pseudo header (computed)

TCP Urgent Pointer (16 bits) Overview Reliable Transp. only meaningful if the URG control bit is set TCP Header used to indicate urgent data in the data field Reliable Transp. positive offset from the sequence number of the segment in TCP Connections points to the sequence number of the first octet after the urgent Congestion Control data Assigned Numbers (= number of “urgent” octets in the data field) Other T. Protocols used to send “out of band” data to applications ignoring normal input e.g. to send a software interrupt to a program in a Telnet session

Options (variable length) zero or more TCP options Case 1: single octet option Case 2: option type (1 oct.), option length (1 oct.), option data

Padding (variable length) makes the TCP header length an integer multiple of 32 bits

TCP Options replace logo

TCP Overview Usage is optional Reliable Transp. TCP Header Option Length in multi-octet options (8 bits) Reliable Transp. gives number of octets in (option type + option length + option in TCP Connections data) Congestion Control Assigned Numbers Options Other T. Protocols End of Option List Type = 0; one octet only No Operation Type = 1; one octet only Maximum Segment Size Type = 2; Length = 4 octets used in SYN segments to indicate the maximum segment size to be received e.g. MSS = MTU-40 or result of path MTU discovery

TCP Overview Maximum given by “Maximum Segment Size” (MSS) Reliable Transp. per direction TCP Header Reliable Transp. default: 536 octets in TCP i.e. 576 octets IP datagram including standard IP and TCP Connections headers Congestion Control Assigned Numbers segment size too small Other T. Protocols large overhead due to sending one IP and TCP header per segment segment size too large risk of fragmentation If one fragment of a segment is lost, the whole segment must be retransmitted (no reliable transport on the IP Layer). Path MTU discovery [RFC 1191] send large segment with IP “don’t fragment” bit set reduce packet size and retry until no ICMP “fragmentation needed” message comes back

3.1.4 Reliable Transport in TCP replace logo

TCP Overview Send Segment Reliable Transp. segmentize send buffer TCP Header send segment with piggybacked current acknowledgement Reliable Transp. in TCP put segment into retransmission buffer and set retransmission Connections timer Congestion Control Receive Segment Assigned Numbers put data into receive buffer Other T. Protocols evaluate piggy-backed acknowledgement take segment(s) from retransmission buffer reset timer send acknowledgement (piggy-backed if possible) inform user process about Push or Urgent data Retransmission Timeout send first segment in retransmission queue again re-initialize retransmission timer wait for acknowledgement (different implementations!)

TCP Overview Reliable Transp. 32 bit Sequence and Acknowledgement Numbers TCP Header Reliable Transp. cumulative acknowledgements in TCP Connections ACK gives “next octet expected” Congestion Control i.e. acknowledgement of all contiguously received octets Assigned Numbers segments received after lost packet cannot be acknowledged [NACK would be possible here!] Other T. Protocols

Retransmission if acknowledgement is missing after timeout adaptive timeout trying to follow network delay (route and load change) avoid unnecessary timeouts allow fastest possible reaction to loss Retransmission can include more data than the original segment!

Retransmission Timer replace logo

TCP Overview Adaptive timeout value Reliable Transp. adapt to a wide variety of network delays TCP Header Reliable Transp. Estimate round trip time (RTT) in TCP Connections record time between sending a segment and receiving its Congestion Control acknowledgement Assigned Numbers Exponential average (old specification) Other T. Protocols = α ⋅ + − α ⋅ RTTavg RTTold (1 ) RTTnewSample smoothing factor α∈(0,1) determines reaction speed α→0 : fast response; α→1 : stable value but slow response β⋅ Retransmission Timeout = RTTavg β=1 : no delay tolerance, fast detection of packet loss β>1 : fewer unnecessary retransmission, slower loss detection Problem High variance of network delay (high load) leads to unnecessary retransmissions -> include observed variance

TCP Overview Reliable Transp. New (1989) specification [RFC1122] TCP Header Reliable Transp. RTT samples xi in TCP Connections ∆ = − x xi xi−1 Congestion Control ~ = +δ ⋅∆ Assigned Numbers x xi−1 x ... average RTT Other T. Protocols σ = σ + ρ ⋅ ∆ −σ i i−1 ( x i−1) ... RTT variance = ~ +η ⋅σ ... timeout heuristic TO x i

Efficient computation choose inverse powers of 2 for δ and ρ perform integer arithmetic by scaling correspondingly e.g. δ=1/8, ρ=1/4, η=2 or 4, scale results by factor of 8

TCP Retransmission Timer replace logo Example Trace

TCP Overview 160 Reliable Transp. RTT TCP Timeout TCP Header 140 Reliable Transp. in TCP Connections 120 le: TThhiiss eexxaammpple: Congestion Control tingg PPooiinntt 100 FFllooaatin Assigned Numbers CCaallccuullaattiioonn Other T. Protocols 80

RTT in ms 60

0 1100 1150 1200 1250 1300 Sample Number

TCP Acknowledgement Ambiguity Overview In the case of a retransmission, does the ACK correspond to Reliable Transp. TCP Header a) the original or Reliable Transp. b) the retransmitted segment? in TCP a) leads to unbounded growth due to increased timeouts Connections b) can lead to a steady state of retransmission time < RTT Congestion Control (all segments are transmitted multiple times Assigned Numbers even without any loss) Other T. Protocols Consequence: No RTT update with retransmitted segments! Karn’s Algorithm: update RTT estimates with unambiguous ACKs only in addition: Timer backoff increase timer value for retransmission when timer expires new timeout = γ * computed timeout

γ = 2 (increase retransmission stability) with upper bound reset to normal estimate for next unambiguous ACK

3.1.5 Connection Concept replace logo

TCP Overview Reliable Transp. Connections only exist in end systems TCP Header Reliable Transp. Network Layer is connectionless in TCP Connections Congestion Control No explicit connection identifier Assigned Numbers Other T. Protocols Connection is identified by 5-tuple IP protocol number (6 = TCP) source IP address source port ““SSoocckkeett”” destination IP address destination port

stored in “TCP Control Block” (TCB) plus internal information such as sequence numbers, timer values etc

TCP Message Sequence Chart (MSC) Overview Reliable Transp. Description of communication between processes TCP Header example cases only Reliable Transp. in TCP Connections Process 1 Process 2 Message 1 Timer Congestion Control Message 2 Assigned Numbers Time Other T. Protocols Finite State Machine (FSM) Symbolic description of process and its communication

State_1 State, waiting for next input

X/Y A B State transition triggered by input X producing ouput Y

TCP Connection State Machine replace logo Summary

abc receive / execute local action Start FIN receive / send packet CLOSED active Open / Passive Open / Close / Close / MSL Maximum Segment Lifetime delete TCB create TCB (RFC793: 2 minutes) create TCB delete TCB SYN LISTEN SYN / SYN+ACK SEND / SYN SYN_RCVD SYN_SENT SYN / ACK ACK of SYN / . CLOSE / FIN ESTAB SYN+ACK / ACK CLOSE / FIN FIN / ACK FIN WAIT_1 CLOSE WAIT FIN / ACK ACK of FIN / . CLOSE / FIN FIN WAIT_2 CLOSING LAST-ACK ACK of FIN / . Timeout or ACK of FIN / FIN / ACK delete TCB TIME WAIT CLOSED Timeout = 2MSL / Source: [RFC793] delete TCB

TCP Overview All packet transmissions implicitly supervised by timer Reliable Transp. retransmission if not acknowledged TCP Header Reliable Transp. in TCP Connections reception of an RST segment causes connection to go into Congestion Control CLOSED state Assigned Numbers Other T. Protocols receiving anything in CLOSED state keeps CLOSED state

In ESTAB state, all segments must carry current acknowledgement information

Timer in connection closing procedure helps distinguish old connections (last ACK lost) from new ones 2 MSL = 2 maximum segment lifetimes, i.e. around 4 minutes

TCP Connection State Machine replace logo Passive Open

abc receive / execute local action FIN receive / send packet CLOSED Passive Open / create TCB LISTEN SYN / SYN+ACK SYN_RCVD

ACK of SYN / . ESTAB

abc receive / execute local action FIN receive / send packet CLOSED active Open / create TCB SYN

SYN_SENT

ESTAB SYN+ACK / ACK

TCP Connection State Machine replace logo Other Side closes Connection

abc receive / execute local action FIN receive / send packet

ESTAB FIN / ACK CLOSE WAIT

CLOSE / FIN LAST-ACK Timeout or ACK of FIN / delete TCB CLOSED

abc receive / execute local action FIN receive / send packet

ESTAB CLOSE / FIN FIN WAIT_1 FIN / ACK ACK of FIN / .

FIN WAIT_2 CLOSING ACK of FIN / . FIN / ACK TIME WAIT CLOSED Timeout = 2MSL / delete TCB

Connection Set-up replace logo

TCP Overview Message Sequence Reliable Transp. TCP Header Example: Active Open at Host 1 after Passive Open at Host 2 Reliable Transp. in TCP Host 1 Port A Host 2 Port B Connections CLOSED Congestion Control Assigned Numbers Passive Open Other T. Protocols CLOSED LISTEN Active Open SEQ=x, CTL=SYN SYN SENT SEQ=y, ACK=x+1, CTL=SYN+ACK SYN RECEIVED SEQ=x+1, ACK=y+1, CTL=ACK Time ESTABLISHED ESTABLISHED

“Three-Way Handshake” Synchronisation of sequence numbers

TCP Overview Message Sequence Reliable Transp. TCP Header Example: Host 1 closes connection Reliable Transp. in TCP Connections Host 1 Port A Host 2 Port B Congestion Control ESTABLISHED ESTABLISHED Assigned Numbers CLOSE Other T. Protocols SEQ=x, ACK=y, CTL=FIN+ACK FIN WAIT_1 inform application SEQ=y, ACK=x+1, CTL=ACK CLOSE WAIT

FIN WAIT_2 SEQ=y, ACK=x+1, CTL=FIN+ACK CLOSE LAST ACK SEQ=x+1, ACK=y+1, CTL=ACK Time TIME WAIT CLOSED TIMEOUT = 2 MSL CLOSED

Chapter 3: Transport Layer replace logo

TCP TCP Flow Control serves two purposes: Congestion Control Principle Algorithms Performance Extensions Receiver Flow Control Assigned Numbers adapt sender data rate to receiver speed Other T. Protocols prevent buffer overflow at receiver receiver advertises available buffer space

wouulldd SI mmooddeell,, tthhiiss wo Network Congestion Control IInn tthhee OOSI ! ork LLaayyeerr ttaasskk! avoid network overload bbee aa NNeettwwork prevent packet loss at router buffers in the network “fair sharing” of rates between all TCP connections on a bottleneck link “elastic traffic”: connection bit rate varies according to available capacity TCP traffic cannot adequately be described by a rate profile

Window based flow control replace logo

Rate is determined by transmission window size number of unacknowledged packets / octets a sender is allowed to transmit

Transmission Window = 1 Transmission Window = 2 Transmission Window = 4 Time Time Time ...

TCP Congestion Control Principle Transmission Window determined from minimum of Algorithms advertised receiver window Performance Extensions congestion window Assigned Numbers Other T. Protocols Flow Control Issues zero window probing Silly Window Syndrome avoidance

Congestion Control Problems and Tasks stability fairness

Zero Window Probing replace logo

TCP Receiver advertises window Congestion Control Principle receiver buffer gets filled up Algorithms Performance window size = 0 given in ACK Extensions sender stops transmitting Assigned Numbers maybe except for URGent data Other T. Protocols receiver application empties buffer receiver transmits second ACK with positive window size sender transmits data

ACKs are not protected if ACK with window>0 gets lost, connection could hang forever sender probes zero windows start after one retransmission timeout increase probing interval exponentially (exponential backoff)

TCP Congestion Control Scenario Principle Receiver buffer completely filled Algorithms Performance application empties buffer by accepting small blocks (e.g. 1 Extensions octet) Assigned Numbers receiving TCP sends ACK with small advertised window (1 Other T. Protocols octet) sender transmits small amount of data (1 octet)

Consequence many small packets transmitted high overhead due to packet headers

Countermeasures receiver side: delayed acknowledgements sender side: delayed transmission (Nagle’s Algorithm)

Delayed Window Update replace logo

TCP Congestion Control Principle Idea: avoid sending insignificant window size updates Algorithms either: send ACK segment but do not change window size Performance Extensions or: delay sending ACK segment Assigned Numbers Other T. Protocols After advertising a window size of zero: Update window size only if it is at least half the available buffer or one MSS

Delay sending ACK segments (recommended) after changes in the receive buffer after receiving a data segment

TCP Send an ACK packet only if Congestion Control receive window has significantly changed (see 3-44) or Principle 500ms have passed since a segment to be acknowledged has Algorithms arrived or Performance ry 22nndd sseeggmmeenntt Extensions another segment has arrived before att lleeaasstt eevveery a nowwlleeddggeedd Assigned Numbers and has not been acknowledged yet wwiillll bbee aacckkno Other T. Protocols → Increase chance of piggybacking ACK on answer packet character echo in telnet etc. protocol response in ftp-control, http etc. → Increase chance of ACK updating the window size → Decrease network traffic due to ACK packets cumulative ACK

Disadvantages increased chance of timeouts accuracy of RTT estimates reduced due to fewer samples

Nagle’s Algorithm replace logo

TCP Congestion Control TCP collects data before transmitting a segment Principle Algorithms wait long enough to limit overhead Performance transmit fast enough to ensure delivery Extensions if higher level protocol is waiting Assigned Numbers Other T. Protocols Nagle’s Algorithm put data into output buffer If still waiting for an ACK, wait until MSS can be filled or ACK arrives Do this even if PUSH was requested

This algorithm is self-clocking simple operation no need for extra timer

TCP see also RFC2001: Congestion Control W. Stevens, “TCP Slow Start, Congestion Avoidance, Fast Principle Retransmit and Fast Recovery Algorithms”, Jan. 1997 Algorithms Performance Extensions Congestion control controls the bit rates of TCP connections Assigned Numbers achieve “fair share” for each connection Other T. Protocols reduce unnecessary retransmissions due to packet loss in routers avoid “congestion collapse”

Principle increase rate until congestion is observed (packet loss) or maximum sender transmission rate is reached or maximum receiver advertised window size is reached decrease rate if packet is lost

Rate is controlled via the transmission window size “congestion window” (CWND)

Multiplicative Decrease replace logo

TCP Congestion Control Example for dupACK detection Principle When a packet is lost and Fast Retransmit Algorithms assume the reason is 0 Performance network congestion –99 Extensions ACK 100–199 reduce congestion window Assigned Numbers No. 200–299 by half 30 Other T. Protocols 100 0–399 double the retransmission 200 400–499 timer for the remaining 500–599 packets (backoff) 200 200 200 Packet loss detected 200–299 retransmission timeout duplicate ACK (can be regarded as NACK) 600 600–699 Time ...

TCP Congestion Control CWND/MSS Principle Also called “Slow Start” 1 Algorithms start with CWND of Performance Extensions one segment increase by one Assigned Numbers 2 for each ACK received Other T. Protocols

CWND growth 3 linear increase 4 over segment number exponential increase over time 5 6 7 8 but nnoott sslloowwllyy!! SSttaarrtt ssllooww,, but 9 Time ...

Congestion Avoidance replace logo

TCP Congestion Control Principle Limit exponential growth of congestion window Algorithms “Threshold” = half the window size before previous loss Performance Extensions SSTHRESH = CWND/2 When threshold is reached: Assigned Numbers increase window by 1 segment only when all segments in the Other T. Protocols window have been acknowledged linear increase of the window over time

Window size computed in octets, not packets increase by MSS in slow start phase increase by MSS * MSS / windowSize in congestion avoidance phase

TCP Tahoe Congestion Control Slow Start Principle start at CWND = MSS Algorithms Congestion Avoidance after CWND reaching threshold value Performance Extensions SSTHRESH Assigned Numbers Fast Retransmit after number of duplicate ACKs (e.g. 3), Other T. Protocols retransmit segments without waiting for timeout set SSTHRESH = CWND / 2 perform slow start: set CWND = MSS Reno like Tahoe plus Fast Recovery after receiving dup ACKs (usually 3) Fast Retransmit (reduce CWND by half) schedule transmissions according to incoming ACKs window size = min(AWIN, CWND+nDUP) ACK Acknowledgement AWIN Advertised Window CWND Congestion Window nDUP number of duplicate ACKs © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 3 Edition Summer 2004 3-51

Congestion Control Algorithms (2) replace logo

TCP Congestion Control Principle New Reno Algorithms change in “partial ACK” handling during Fast Recovery Performance Extensions retain Fast Recovery status even if a second packet was lost reduce CWND by half only once Assigned Numbers Other T. Protocols SACK TCP Option (header extension) to allow selective acknowledgements only retransmit the lost segments allows retransmitting more than one segment per RTT

Problem without SACK: either retransmit segments already successfully received or retransmit at most one segment per RTT

TCP Congestion Control Principle Tahoe, Reno, SACK Algorithms use additive increase and multiplicative decrease Performance Extensions sense congestion only through packet loss (timeout or dupACK) Assigned Numbers Other T. Protocols Vegas react to variation in delay as a measure of network load try to keep highest possible rate without loss “tolerance” range to keep CWND constant without change

needs sufficient buffer space to operate well

Congestion Control Algorithms (4) replace logo Vegas

TCP Congestion Control CWND CWND Principle Compute rate difference measure ∆ = − Algorithms RTT RTT Performance base Extensions Assigned Numbers α Other T. Protocols increase CWND by MSS if ∆ < RTTbase α β keep CWND constant if < ∆ < RTTbase RTTbase β decrease CWND by MSS if ∆ > RTTbase

Parameters: α and β (e.g. buffer space occupied in routers)

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 3 Edition Summer 2004 3-54 TCP Congestion Control replace logo Principal Figure om procceessss iiss rraannddom lloossss pro TCP TCP Reno trace indoowwssiizzeess)) ((ddiiffffeerreenntt wwind Congestion Control 35 Principle Algorithms 30 L L Performance L LL L Extensions 25 LL Assigned Numbers 20 CACA CACA Other T. Protocols CACA 15 FRFR FRFR 10 SS 5 TOTO SS Congestion Window Size 0 0 5 10 15 20 25 30 SegmentTime in Number units SS Slow Start FRFR Fast Recovery TOTO Timeout LL Packet Loss CACA Congestion Avoidance

3.2.3 Performance replace logo

TCP Congestion Control Principle Steady State performance of TCP determined by Algorithms packet loss Performance Extensions Round Trip Time (RTT) acknowledgement behaviour Assigned Numbers Other T. Protocols

Assumptions: independent packet losses with probability p constant round trip time RTT receiver generates b ACKs per received packet (b≤1)

TCP Formula derived by Mathis, Semke, Mahdavi, Ott Congestion Control M. Mathis, J. Semke, J. Mahdavi, T. Ott, Principle “The Macroscopic Behavior of the TCP Congestion Avoidance Algorithms Algorithm”, ACM Computer Communication Review 27 (3) Jul. Performance Extensions 1997, available at Assigned Numbers http://www.psc.edu/networking/papers/model_ccr97.ps Other T. Protocols (last checked April 2003)

Mean Congestion Window size 8 E[W ] ≈ max 3bp

Mean Steady State Throughput (in packets per time) MSS 3 B = RTT 2bp

Startup Behaviour replace logo

TCP Congestion Control How long does it take until TCP can utilize the full link Principle bandwidth B? Algorithms Performance No packet loss Extensions Unlimited windows Assigned Numbers One ACK per segment Other T. Protocols Overhead neglected ACK size neglected All data segments have the same size

Parameters: Link speed (line rate) r Round trip time 2τ including all processing delays Segment size s

TCP Cycles of duration RTT’ Congestion Control CWND/MSS Principle 1 Algorithms Channel steady state Performance Extensions when CWND RTT’ Assigned Numbers w(t) ≥ w = RTT '⋅r 2 Other T. Protocols 0 L s = τ + s + ACK RTT ' 2 3 rL rL 4

in RTTs: 5 w(n⋅ RTT ') = 2n ⋅ s 6 7 ⋅ 8   RTT ' rL  = 9 Time n0 ld    s  ...

Startup Behaviour (3) replace logo

TCP Congestion Control Principle time to reach steady state Algorithms Performance = ⋅ Extensions t0 n0 RTT ' Assigned Numbers Other T. Protocols data transmitted during slow start n ⋅(n +1) S = 0 0 s 0 2

Extensions delayed acknowledgements increased initial windows

TCP Congestion Control Explicit Congestion Notification (ECN) Principle Algorithms set an “ECN” bit instead of dropping packets Performance set ECN bit if buffer levels are above a threshold, Extensions so additional packets can still be stored Assigned Numbers control TCP congestion window without requiring Other T. Protocols retransmission reverse transmission needed needs support in routers and end systems

Random Early Detection (RED) avoid source synchronisation by introducing queue threshold to randomly drop packets independent implementation in routers (“IP gateways”) performance improvement depends on scenario (questionable)

Chapter 3: Transport Layer replace logo

TCP Congestion Control Port (dec.) keyword description Assigned Numbers 0–reserved Other T. Protocols 7 echo echo what is received 9 discard discard all received information 13 daytime answer with date and time 19 chargen character generator 20 ftp data File Transfer Protocol data connections 21 ftp FTP control connections 23 telnet telnet server 25 smtp Simple Mail Transfer Protocol: Mail server 53 domain Domain Name Server (DNS) 67 bootps bootp or DHCP server 68 bootpc bootp or DHCP client 69 tftp trivial file transfer protocol 70 gopher gopher (text based predecessor of the Web) 80 http Hypertext Transport Protocol server 88 kerberos Kerberos security service

3.3 Assigned Numbers replace logo Well known TCP port numbers

TCP Congestion Control Port (dec.) keyword description Assigned Numbers 110 pop3 Post Office Protocol version 3 Other T. Protocols 119 nntp Network News Transfer Protocol 123 ntp Network Time Protocol 137, 138, 139 netbios Netbios Name, Datagram and Session Services 177 xdmcp X Display Manager Control Protocol 443 https Secure Socket Layer HTTP 6000 X11 X Window

longer list: see RFC1700

3.4 Other Transport Protocols replace logo

TCP Congestion Control Two Examples Assigned Numbers Other T. Protocols SCTP Stream Control Transport Protocol Message oriented reliable transport

RTP Real Time Transport Protocol unreliable transport of media stream data e.g. for voice or video streams

TCP Stream Control Transmission Protocol Congestion Control Assigned Numbers General Purpose transport protocol Other T. Protocols Specified in RFC 2719 (architecture), RFC 2960 (protocol) SCTP RTP Datagram (message) transport Flexible out-of-order delivery can be specified per message stream compatible with TCP’s congestion control tends to take same fair share of bandwidth as a TCP connection support of multi-homed nodes network / path redundancy can increase reliability protection against blind attacks

SCTP replace logo Datagram (Message) Transport

TCP In contrast to TCP where Congestion Control an application layer protocol has to separate Assigned Numbers messages in a stream Other T. Protocols SCTP RTP Connection (“association”) oriented protocol based on IP could also run over UDP Reliable message transport acknowledged delivery error-free delivery no duplicates delivered Message based fragmentation of large messages into multiple datagrams bundling (multiplexing) of small messages in one datagram No timing guarantees

TCP Congestion Control Original application: Transport of telephone signalling data Assigned Numbers over IP Other T. Protocols e.g. #7 (SS7) messages SCTP SS7 MTP-2 User Adaptation RTP SS7 MTP-3 User Adaptation IUA: ISDN Q.921 User Adaptation SUA: SS7 SCCP User Adaptation no need for extra protocol to delineate messages in a TCP stream compatibility with TCP flow control allows use in any IP network

could be used with any application that needs reliable message transport SIP control over SCTP e.g. HTTP over SCTP

SCTP replace logo Connection Set-Up

TCP Congestion Control Packets are called “chunks” Assigned Numbers separation of data and control chunks Other T. Protocols SCTP Four-way startup handshake RTP signed cookies prevent blind spoofing verification tags prevent insertion of extraneous packets

Host A Host B INIT(Initiate Tag A; list of IP Addresses: A1, A2, ...; Port A) INIT ACK(Cookie; Initiate Tag B; list of IP Addresses: B1, B2, ...; Port B) Cookie Echo (Cookie)

Cookie ACK

TCP Real-Time Transport Protocol Congestion Control Assigned Numbers described in RFC 1889 Other T. Protocols uses UDP SCTP to access IP RTP to provide multiplexing (concurrency) multiple RTP messages can be combined into one UDP datagram RTCP (RTP Control Protocol) out of band communication adapt to bandwidth communication about ports used message types: 200 Sender Report 201 Receiver Report 202 Source Description Message 203 Bye Message 204 Application Specific Message

RTP replace logo Features

TCP Port allocation etc Congestion Control provides time stamps Assigned Numbers help applications to synchronize playback Other T. Protocols provides sequence number SCTP help applications to detect loss or out-of-order delivery of RTP packets different profiles defined describe interpretation of packet contents use standard codecs Translation Support to change contents encoding at designated nodes (media gateway) Mixing Support to mix e.g. several audio signals for an audio/video conference Bandwidth allocation and scheduling not included to be supported by IP network if needed

TCP Congestion Control Bit positions: Assigned Numbers 0 1 2 3 Other T. Protocols 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 SCTP Ver P X CC M PTYPE Sequence Number RTP Timestamp Synchronization Source Identifier Contributing Source ID ...

f 12 bbyytteess MMiinniimmuumm oof 12 r paacckkeett!! oovveerrhheeaadd ppeer p

RTP replace logo Header Fields

TCP Version (2 bits) Congestion Control currently 2 Assigned Numbers Other T. Protocols P bit (1 bit) SCTP 1 if zero padding follows the payload RTP X bit (1 bit) 1 if optional header extension is present depends on application type CC: source count (4 bits) maximum of 15 contributing sources is supported M: Marker bit (1 bit) application dependent mark events in data stream e.g. frame start in video streams PTYPE: Payload Type (7 bits) determines detailed interpretation of header and contents

TCP Congestion Control Sequence Number (16 bits) Assigned Numbers identifies RTP packets Other T. Protocols initial sequence number chosen randomly for each session SCTP Timestamp (32 bits) RTP time at which the first octet of digitized data was sampled (relative) random choice of initial time stamp continuously incremented clock granularity depends on application Synchronization Source Identifier (32 bits) identifies the source of a stream real source, mixer or translator identification collisions resolved by protocol Contributing Source ID (variable size, CC x 32 bits) list of source identifiers that contributed the samples mixed together by a mixer

Questions replace logo

TCP 3.1 Can two TCP applications establish a connection if they both Congestion Control issue an “active” open call? (Hint: Check the TCP connection Assigned Numbers state diagram) Other T. Protocols 3.2 Can an application open two parallel TCP connections to the same server at the same server port? Questions 3.3 Collect all the well-known port numbers for the protocols shown on slide 2-11. Does each protocol have an assigned number? What would happen if a server offered a protocol on another than the well-known port?

3.4 How is message delineation done in SMTP? in HTTP? 3.5 What is a “persistent connection” in HTTP? 3.6 How can a computer learn its configuration using DHCP?

Information and Communication Networks

IP Based Networks and Applications Chapter 4: Applications and Application Layer Protocols

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Highest Layer of the communication reference model

Application Layer protocols are used by applications offer an API define data structures define interaction between communication partners

Use TCP or UDP to transport data over IP

Offers API to applications or is built into applications

Chapter 4: replace logo Applications and Application Layer Protocols

Introduction 4.1 Introduction 4.4 HTTP DNS 4.1.1 Design Principles E-Mail 4.1.2 Contents Delineation 4.5 Telnet HTTP 4.1.3 Client-Server Paradigm 4.6 FTP Telnet 4.1.4 Reply Codes FTP 4.1.5 Socket Concept 4.7 VoIP VoIP 4.2 DNS 4.7.1 Packetized Voice 4.7.1 H.323 4.3 E-Mail 4.7.2 SIP 4.3.1 SMTP 4.3.2 MIME 4.3.3 POP3 4.3.4 IMAP

Introduction Design Principle End-to-end principle Delineation communication does not rely on functions in the network Client-Server end-to-end check is necessary anyway Reply Codes even if Layer 3 was perfect, end systems could fail Socket Concept [J.H. Saltzer, D.P. Reed, D.D. Clark: “End-To-End Arguments in DNS System Design”, E-Mail ACM Trans. Comp. Systems, Vol. 2 No. 4 Nov. 1984 pp. 277–288] HTTP Telnet Many ASCII Protocols FTP Most protocols use text based commands and replies VoIP easier to debug (and implement) than binary coded protocols nd HHTTTTPP sseeee SSMMTTPP aand Abstractions Network Virtual Terminal (NVT) virtual file system d FFTTPP sseeee tteellnneett aannd

4.1.2 Contents Delineation replace logo

Introduction Operation of an application layer protocol Design Principle exchange control messages between endpoints Delineation Client-Server exchange (user) data between endpoints Reply Codes Socket Concept control messages and user data can be larger than one DNS packet size E-Mail HTTP → no simple extension of the “header” concept Telnet Application Layer: FTP VoIP App.L. CM UD CM UD ...

Tr.L. H PL H PL H PL H PL H PL H PL H PL ...

IP and TCP Layer: Application Layer: H TCP and IP headers CM control message PL payload UD user data © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-6 Control Message Delineation replace logo

Introduction TCP transfers an octet stream Design Principle mapping of protocol messages into packets is not reliable Delineation PUSH mechanism may still deliver multiple messages per Client-Server packet (see Nagle’s algorithm in Sec. 3.2.1) Reply Codes messages may be longer than MSS and split across packets Socket Concept → multiple packets’ payloads must be concatenated DNS E-Mail → HTTP messages must be delineated within the octet stream Telnet “end-of-line” codes FTP mostly for ASCII text message based protocols VoIP one message per “line” “end-of-line” must be defined, e.g. as the [CR][LF] sequence examples: HTTP, SMTP, POP, IMAP “type-length-value” (TLV) encoding also used in the IP and TCP options header fields example: SNMP (doing it with ASN.1, see Sec. 8.6)

Separation of Control Messages and User Data replace logo

use separate connections for control and user data Introduction connection endpoints must communicate about f-baanndd”” Design Principle ““oouutt--oof-b user data connections to open and close Delineation addresses and port numbers exchanged between endpoints Client-Server → problems with NAT, firewalls and IPv4/v6 transition Reply Codes examples: FTP, H.323, SIP (voice over IP) Socket Concept special character sequences separate control and user data DNS character sequence must be escaped if it occurs in user data E-Mail example: SMTP using “a period on a single line by itself” HTTP -baanndd”” Telnet content length encoding ““iinn-b FTP specify content length of user data in control messages VoIP content length must be known in advance easy to get desynchronized non-transparent networks (should not be a problem anymore) lazy programmers might mis-calculate lengths example: HTTP If the content length was unknown before transmission (e.g. in dynamically created pages), the HTTP server closes the connection to mark the end of a transferred element.

Introduction Design Principle Server Delineation can be reached via an IP network Client-Server offers a service Reply Codes denotes a software process, not a piece of hardware Socket Concept accepts connections / requests on a (well-known) port DNS runs “forever” E-Mail must be protected against incorrectly communicating clients HTTP protocol implementation errors Telnet network and/or run-time errors (especially for UDP servers) FTP attacks (e.g. denial of service attacks) VoIP

Client connects to server over an IP network process runs only as long as needed can use any port

Server Principle replace logo

Introduction Design Principle Use multiple processes or threads to be able to serve Delineation multiple clients at the same time Client-Server Reply Codes Master Server Socket Concept open a (well-known) port DNS wait for a new client E-Mail if necessary, choose a new local port and inform the client HTTP start slave process handle one request or connection and then terminate Telnet continue waiting FTP VoIP authorization and protection measures for stable / continuous operation

Introduction ASCII based protocols use a system of reply codes to Design Principle indicate success or failure status Delineation SMTP: RFC 821 Client-Server FTP: RFC959 Reply Codes HTTP V1.1: RFC 2616 Socket Concept 3-digit codes of form xyz DNS E-Mail 1st digit gives general success class indication HTTP success / failure / action requied Telnet 2nd digit can specify sub-cases within class (specified by FTP first digit) VoIP 3rd digit used to further specify sub-cases

communication partners (clients) need not know all combinations from unknown code xyz, fall back to xy0 or x00 e.g. From “203 non-authoritative information” to “200 OK”

Reply Codes replace logo First Digit

Introduction 1yz: Positive Preliminary Reply Design Principle informational Delineation e.g. Request received, continuing process Client-Server Reply Codes Socket Concept 2yz: Positive Completion Reply, Success DNS E-Mail 3yz: Positive Intermediate Reply, HTTP further action required to complete the request Telnet e.g. Redirection FTP VoIP 4yz: Transient Negative Completion Reply, Client Error Request/command contained bad syntax and cannot be fulfilled

5yz: Permanent Negative Completion Reply, Server Error Request may have been valid but cannot be fulfilled by server

Introduction Design Principle x0z: Syntax Delineation Client-Server Reply Codes x1z: Information Socket Concept DNS E-Mail x2z: Connections HTTP Telnet FTP x3z: Authentication and Accounting VoIP replies for login processes and accounting procedures

x4z: unspecified

x5z: File System / Mail System

Reply Codes replace logo Examples from RFC2616 (HTTP 1.1)

Introduction 100 Continue 404 Not Found 101 Switching Protocols 405 Method Not Allowed Design Principle 200 OK 406 Not Acceptable Delineation 201 Created 407 Proxy Authentication Client-Server 202 Accepted Required 203 Non-Authoritative 408 Request Time-out Reply Codes Information 409 Conflict Socket Concept 204 No Content 410 Gone DNS 205 Reset Content 411 Length Required E-Mail 206 Partial Content 412 Precondition Failed 300 Multiple Choices 413 Request Entity Too Large HTTP 301 Moved Permanently 414 Request-URI Too Large Telnet 302 Found 415 Unsupported Media Type FTP 303 See Other 416 Requested range 304 Not Modified not satisfiable VoIP 305 Use Proxy 417 Expectation Failed 307 Temporary Redirect 500 Internal Server Error 400 Bad Request 501 Not Implemented 401 Unauthorized 502 Bad Gateway 402 Payment Required 503 Service Unavailable 403 Forbidden 504 Gateway Time-out 505 HTTP Version not supported

Introduction Applications can use different levels of network abstraction Design Principle use TCP, UDP or raw IP interface Delineation use higher layer abstractions (RPC, Xlib, Corba) Client-Server Reply Codes Socket Concept provides interface to TCP and UDP (and Socket Concept raw IP) DNS TCP/IP connects two sockets E-Mail similar to Unix file descriptor HTTP positive integer value but without seek, open, permissions Telnet “stream” communication: TCP socket FTP “datagram” communication: UDP socket VoIP

Host A Host B process IP process Network Socket Socket TCP Connection

Sockets replace logo System Calls

Introduction Design Principle int socket() Delineation create a socket select protocol (TCP, UDP, Raw IP) Client-Server int bind() Reply Codes select a port number, maybe an IP address Socket Concept system can choose random local port DNS set port number to 0 E-Mail for client processes HTTP int connect() Telnet “active open” FTP int listen() VoIP “passive open”: wait for incoming connections int accept() accept an incoming connection returns a new socket int close() close a socket

Introduction routines provided by library Design Principle Delineation Client-Server conversion between network and host byte order Reply Codes network to host: ntohl() Socket Concept host to network: htonl() DNS 16bit integer versions: ntohs(), htons() t E-Mail e iissssuuee aabboouut rreemmeemmbbeerr tthhe HTTP iann ssyysstteemmss lliittttllee//bbiigg eennddia Telnet FTP conversion from host name to numeric address: VoIP gethostbyname()

dotted quad to integer: inet_addr() integer to dotted quad: inet_ntoa()

Sockets replace logo Client / Server Interaction

Introduction Server Design Principle s=socket(...) Delineation Client-Server bind(s, ...) Reply Codes listen(s, ...) Client TCP Socket Concept c=socket(...) DNS a=accept(s, ...) Connection Set-Up E-Mail (blocking) connect(c, ...) HTTP Telnet read(a, ...) request FTP (blocking) write(c, ...) VoIP read(c, ...) reply write(a, ...) (blocking)

close(a, ...) close(c, ...)

Introduction Design Principle Code is available from Delineation http://www.jcho.de/jc/IPNA/myWebServer.cc Client-Server Reply Codes Socket Concept create socket s DNS bind to given port E-Mail HTTP listen Telnet accept connection FTP print connection source IP address VoIP print received data menue to select data to send (different standard HTTP replies) close connection

Chapter 4: replace logo Applications and Application Layer Protocols

Introduction 4.1 Introduction 4.4 HTTP DNS 4.1.1 Design Principles E-Mail 4.1.2 Client-Server Paradigm 4.5 Telnet HTTP 4.1.3 Reply Codes 4.6 FTP Telnet 4.1.4 Socket Concept FTP 4.7 VoIP 4.2 DNS VoIP 4.7.1 Packetized Voice 4.3 E-Mail 4.7.1 H.323 4.3.1 SMTP 4.7.2 SIP 4.3.2 MIME 4.3.3 POP3 4.3.4 IMAP

Introduction Domain Name System DNS RFCs 1034/1035, 1101, 2535 E-Mail server port: 53 (UDP and TCP) HTTP Telnet Distributed Directory System for Internet Names FTP map names to IP addresses VoIP local name servers and root name servers use caching (-> non-authoritative answers) Hierarchical Name Space labels separated by periods hypothetical example: host1.netlab.ind.ei.uni-stuttgart.de Delegation of Authority for parts of the name space Reverse Lookup get name for an IP address e.g. ask for 76.1.69.129.in-addr.arpa to look up name for 129.69.1.76

DNS replace logo

Introduction Domain hierarchy DNS subdomains E-Mail host names (same syntax as domain names) HTTP Domain name extensions Telnet allows resolution of partly specified domain names FTP e.g. “www” or “www.ei” VoIP not part of the domain name system specification (introduced by resolvers) final period suppresses extension server hierarchy ask local server first root name servers need to know all top level domain (TLD) servers different hierarchies for naming (DNS) connectivity (networks) IP address allocation

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-22 DNS replace logo Resource Record Types A Host Address 32 bit IP address Introduction CNAME Canonical Name canonical name for an alias DNS E-Mail HINFO CPU and OS type of CPU HTTP and operating system Telnet MINFO Mailbox Information information about mailbox FTP or mail list VoIP MX Mail Exchanger 16 bit preference value and name of host that handles e-mail for the requested domain NS Name Server name of an authoritative name server for the requested domain PTR Pointer domain name (for reverse lookup) SOA Start of Authority multiple fields giving the parts of the hierarchy the server is responsible for TXT Arbitrary Text uninterpreted string of ASCII text © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-23

DNS replace logo Protocol

Introduction Based on UDP DNS single packet request (from any port x to port 53) E-Mail single packet response (from port 53, mostly back to port x) HTTP Message Format: Telnet FTP 0 16 31 VoIP Identification Parameter Number of Questions Number of Answers Number of Authority Records Number of Additional Records Question Section ... Answer Section ... Authority Section ... Additional Information Section ...

Introduction DNS Bit Meaning E-Mail HTTP 0 Operation 0 = Query, 1 = Response Telnet FTP 1–4 Query Type 0 = Standard, 1 = Inverse, 2,3: obsolete VoIP 5 Answer is authoritative 1 = authoritative 6 Message is truncated 1 = truncated 7 Recursion requested 1 = recursion requested 8 Recursion available 1 = recursion was available 9–11 reserved 12–15 Response Type 0 = No error, 1 = Format error in query 2 = Server failure, 3 = Name does not exist

DNS replace logo Section Formats

lenggtthh ffiieellddss,, Question Section ** aarrbbiittrraarryy len written by client nnoott ppaaddddeedd server returns question along with answer to maintain context in connectionless communication 01631 Query Domain Name ...* Query Type Query Class

Answer, Authority, Additional Information Sections written by server Resource Domain Name ...* Type Class Time to Live Resource Data Length Resource Data ...*

Introduction DNS Domain names stored as sequence of “labels” E-Mail succession of 1 octet length n and n octets label (ASCII) HTTP length = 0: end of name Telnet labels restricted to 63 characters (top 2 bits of length value are FTP zeroes) VoIP 00 Length Label 00 Length Label 00000000 e.g. a . edu

Repetition of domain names in packets avoided by pointers if top 2 bits of length value are set to one, interpret the following 14 bits as a pointer (offset from start of message; 0 = first octet of ID field) 11 Pointer

Chapter 4: replace logo Applications and Application Layer Protocols

Introduction Message delivery to address DNS Asynchronous delivery E-Mail Addresses: identification@mailhost SMTP mailhost: MIME host name or mail exchanger (MX) entry in DNS POP3 identification: IMAP user name, redirected mailbox or mailing list (“mail exploder”) HTTP oulldd bbee Telnet Maaiill sseerrvveerr sshhou M e tiimmee FTP Alias oonnlliinnee aallll tthhe t VoIP send Database mail Alias Expansion Spool Area Mail and Forwarding (outgoing mail) Client

read mail Mailboxes Mail User Interface (incoming mail) Server TCP/IP data transport: SMTP

E-Mail Concept replace logo Mail Relays

Introduction E-Mail can be delivered indirectly for different reasons DNS E-Mail Offline Mailboxes SMTP access e.g. via POP, IMAP MIME POP3 Back-Up servers IMAP use lower priority “mail exchanger” when primary mail host is HTTP down Telnet Explicit (source) routing FTP identification%mailhost@relay VoIP Multi-hop delivery to build address hierarchy, hide local addresses in private networks to have central mail gateway e.g. for an organisation to perform central filtering functions, e.g. Virus removal

Protocol conversion

Introduction DNS Mail client checks DNS “MX” (mail exchanger) entry E-Mail often multiple entries with different priority values SMTP client tries to open an SMTP/TCP connection to the highest MIME priority (lowest value) mail exchanger POP3 if connection fails, try the next priority mail exchanger IMAP HTTP Telnet Mail servers can have symbolic names for e-mail (DNS MX FTP records) that are invalid host names (no A record) VoIP often: MX record with the domain name

4.3.1 SMTP replace logo

Introduction Simple Mail Transfer Protocol DNS Protocol for Mail exchange between machines E-Mail specified in RFC 821 (SMTP) and RFC 822 (message format) SMTP server port: 25 (TCP) MIME POP3 IMAP simple protocol HTTP text based Telnet commands separated by CRLF (carriage return, line feed) FTP sequence VoIP few commands

several extensions Service Extensions (RFC 1869) Service Extension for Message Size (RFC 1870) 8-bit MIME transport (RFC 1652) MIME (RFC 2045)

Introduction Reply Codes DNS HELO give client name E-Mail MAIL FROM give sender e-mail address SMTP MIME RCPT TO give recipients’ e-mail addresses POP3 DATA transmit a message IMAP ended by a period (“.”) on a single line HTTP QUIT end of conversation, close TCP Telnet FTP connection VoIP Additional Commands TURN exchange roles of client and server EXPN expand an alias VRFY verify existence (correctness) of an address RSET reset all buffers and state information HELP send helpful information NOOP do not do anything, just send an OK SEND, SOML, SAML: “send” function in addition to “mail”

SMTP replace logo Conversation Example

Introduction Minimum conversation between client (C) and server (S) DNS E-Mail S:S: 220 220 host-a.nethost-a.net readyready SMTP C:C: HELO HELO host-b.eduhost-b.edu MIME S:S: 250 250 host-a.nethost-a.net POP3 C:C: MAIL MAIL FROM:FROM: IMAP S:S: 250 250 OKOK HTTP C:C: RCPT RCPT TO:TO: Telnet S:S: 250 250 OKOK C: DATA FTP C: DATA S:S: 354 354 StartStart mailmail input;input; endend withwith .. VoIP C:C: Hi, Hi, thisthis isis mymy testtest mailmail toto youyou allall C:C: which which extendsextends overover aa fewfew lineslines C:C: ...... C:C: . . S:S: 250 250 OKOK C:C: QUIT QUIT S:S: 221 221 mailserver.mynet mailserver.mynet closing closing connection.connection. ThanksThanks forfor youryour message.message.

Introduction Message “Envelope” given in SMTP protocol DNS E-Mail Message Headers for addresses and functions SMTP for SMTP, headers are part of the mail “data” MIME Syntax: Field-name: field-body POP3 only printable ASCII characters (33–126, except colon) allowed IMAP Usual header fields HTTP “From:” specifies the sender Telnet “To:” specifies a list of recipients FTP “Cc:” “carbon copy” (more recipients) VoIP “Bcc:” “blind carbon copy”, recipients not to be shown “Return-Receipt-To:” to request a mail back after delivery / reading “Subject:” the subject of the mail extendible concept even private (proprietary headers) can be used

SMTP replace logo Example with headers

Introduction After HELO sequence... DNS E-Mail C:C: MAIL MAIL FROM:FROM: SMTP S:S: 250 250 OKOK MIME C:C: RCPT RCPT TO:TO: POP3 S:S: 250 250 OKOK IMAP C:C: DATA DATA HTTP S:S: 354 354 StartStart mailmail input;input; endend withwith .. Telnet C:C:From: From: [email protected]@a.edu C: To: [email protected] FTP C: To: [email protected] C:C:Return-Receipt-To: Return-Receipt-To: [email protected]@org-a.org VoIP C:C:Subject: Subject: QuestionQuestion onon SMTPSMTP C:C: Hi Hi user2,user2, dodo youyou likelike thethe SMTPSMTP protocol?protocol? C:C: Cheers, Cheers, user3.user3. C:C: . . S:S: 250 250 OKOK C:C: QUIT QUIT S:S: 221 221 mailserver.mynet mailserver.mynet closing closing connecconnection.tion. ThanksThanks forfor youryour message.message.

Introduction DNS Multimedia Internet Mail Extensions E-Mail SMTP specified in RFCs 2045–2049 MIME POP3 used to encapsulate files in e-mails keeping plain text format IMAP content type description es HTTP tely,, MMIIMMEE ddooes base64 encoding UUnnffoorrttuunnaately ... Telnet commpprreessssiioonn... not ssppeecciiffyy ffiillee co FTP not VoIP MIME headers “MIME-Version:” “Content-Type:” “Content-Transfer-Encoding:”

multipart messages with specification of boundary text

MIME replace logo Types

Introduction Specified in the “Content-Type:” header DNS E-Mail text for textual documents SMTP MIME image for still (at most: animated) images POP3 audio for sound recordings IMAP HTTP video for video recordings Telnet application raw data for another program FTP multipart multiple parts VoIP each part has its own content type and encoding specification further specification of viewing sequence (parallel, alternative) message a complete e-mail message or reference to a file

format can be further specified e.g. “Content-Type: image/gif”

Introduction DNS Post Office Protocol E-Mail RFC 1939 SMTP server port: 110 (TCP) MIME POP3 protocol to access mailboxes (“maildrops”) on remote IMAP computers HTTP mailbox is on a computer with permanent Internet connectivity Telnet read mail on a computer that only has a dial-up connection FTP send mail via SMTP VoIP

Functions login (mailbox selection) authentification (password) read, delete mails Message transfer format according to RFC822

POP3 (2) replace logo

Introduction Client commands DNS 3 or four characters ASCII, case insensitive E-Mail arguments separated by a single space character SMTP up to 40 characters per argument MIME termination by CRLF POP3 Server responses IMAP status indicator (“+OK” or “-ERR”) HTTP additional information (max. 512 characters total) Telnet multi-line response terminated by CRLF.CRLF FTP VoIP Authorization State commands: USER+PASS or APOP or QUIT Transaction State commands: STAT, LIST, RETR, DELE, NOOP, RSET, (TOP, UIDL) Update State commands: QUIT

Introduction Example conversation between client (C) and server (S) DNS E-Mail S:S: +OK +OK POP3POP3 serverserver readyready <[email protected]><[email protected]> SMTP C:C: APOP APOP mrose mrose c4c9334bac560ecc979e58001b3e22fb c4c9334bac560ecc979e58001b3e22fb MIME S:S: +OK +OK mrose’s mrose’s maildropmaildrop has has 22 messagesmessages (320(320 octets)octets) C: STAT POP3 C: STAT S:S: +OK +OK 22 320320 IMAP C:C: LIST LIST HTTP S:S: +OK +OK 22 messagesmessages (320(320 octets)octets) Telnet S:S: 1 1 120120 S: 2 200 FTP S: 2 200 S:S: . . VoIP C:C: RETR RETR 11 S:S: +OK +OK 120120 octetsoctets S:S: (sends (sends messagemessage 1)1) S:S: . . C:C: DELE DELE 11 S:S: +OK +OK messagemessage 11 deleteddeleted C:C: QUIT QUIT S:S: +OK +OK dewey dewey POP3 POP3 serverserver signingsigning offoff

Source: RFC1939 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-41

4.3.4 IMAP replace logo

Introduction DNS Internet Message Access Protocol E-Mail RFC2060 SMTP server port: 143 (TCP) MIME POP3 protocol for remote mailbox access IMAP receive mail HTTP manipulate mailboxes Telnet send mails via SMTP FTP VoIP in addition to POP3: mailbox management dynamic creation, deletion, modification of accounts / mailboxes association of flags to messages searching of messages server can notify client of new messages during session

4.4 HTTP replace logo

Introduction DNS Hypertext Transfer Protocol (RFCs 1768, 1945, 2616, 2617) E-Mail TCP used for reliable transport HTTP server port: 80 (TCP) but others can be specified in URL Telnet bi-directional transport for request/response FTP Request/response operation VoIP Stateless self-contained requests no state kept in server augmented by the “cookies” concept (store state in clients) Capability selection client lists e.g. supported character sets, server selects one Caching support HTTP allows to retrieve file properties only (“HEAD” method) Support for proxies

Simple protocol to retrieve (and submit) files Introduction much simpler than ftp DNS methods to retrieve (and send) files E-Mail HTTP GET, HEAD, POST, PUT, OPTIONS, DELETE, TRACE, CONNECT Telnet FTP headers (like E-Mail) to transport additional information VoIP Uniform resource locator (URL) for addressing “http://” hostname [ “:”port ] [ abs_path [ “?”query ] ] relative URL: without the “http:// hostname” [“:”port] part Markup language HTML describes structured contents MIME notation to inform receiver about file types in addition, receivers judge file types from file name endings HTTP proxies as gateways for

SMTP, NNTP, FTP, FTP File Transfer Protocol Gopher, WAIS HTML Hypertext Markup Language MIME Multipurpose Internet Mail Extensions Byte-range requests NNTP Network News Transfer Protocol SMTP Simple Mail Transfer Protocol allow completion of URL Uniform Resource Locator interrupted transfers WAIS Wide Area Information Service © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-45

HTTP replace logo HTML

Introduction Hypertext Markup Language DNS first versions defined in RFCs 1866, 1867, 1942 E-Mail nowadays developed in W3C (World Wide Web Consortium, HTTP w3c.org) Telnet FTP Tags VoIP to start environment x to end environment x Page contents text images hyperlinks Page layout information structuring frames Page meta information author, tools, keywords

Introduction DNS <HEAD><TITLE>ExampExamplele PagePage E-Mail HTTP BGCOLOR=“#FFFFC0”> Telnet

ExampleExample HeadingHeading

This This isis justjust aa testtest page.page. FTP LectureLecture materialmaterial isis availableavailable ininhttp://www.jcho.de/jc/IPNA/”> thisthis placeplace..

HTTP replace logo Error Messages

Sent in HTML Introduction DNS Page title () contains 3-digit reply code E-Mail reply messages are often configurable HTTP reply codes see page 4-14 Telnet Example: FTP VoIP <HEAD><TITLE>400400 BadBad RequestRequest

BadBad RequestRequest

Your Your browserbrowser sentsent aa requestrequest thatthat thisthis servserverer couldcould notnot understand.understand.

Introduction DNS More than one item transfered in one connection E-Mail HTTP/1.0: requested by “Connection: Keep-alive” header HTTP default in HTTP/1.1 Telnet require indication of content length (“Content-Length” FTP header) VoIP for dynamic pages, the length is not known before transmission server notifies the client sends “Connection: close” header instead of “Content-Length” closes the connection after transmission (see p. 4-8)

Pipelining (HTTP/1.1) send multiple GET requests without waiting for response increase TCP efficiency for transfers of small elements problem with servers closing connections

HTTP Requests and Persistent Connections replace logo

Minimum connection Persistent connection Client Server SYN

SY Client TCP N SYN+ACK Server Conn. SYN+ACK ACK Setup Keep-alive + GET A CK Data GET... Data GET+ACK ata Transfer D Data ACK ACK FIN TCP GET Conn. FIN+ACK Data Timeout (e.g. 15sec)

Release Timeout (e.g. 15sec) ACK ACK

FIN

Introduction DNS Caching E-Mail store file locally HTTP use local copy when same file is requested again Telnet reduce network traffic FTP ageing mechanism VoIP retrieve again only if local copy is “old” conditional requests retrieve again only if file has changed e.g. “If-Modified-Since: Sun, 03 Jun 2001 16:12:25 GMT” server can respond with “304 Not Modified” browser can force revalidation of page Proxy Support used to separate networks often combined with caching explicitly supported in HTTP/1.1 e.g. “Max-Forwards:” header

HTTP replace logo Format Negotiation

Introduction DNS Browser can tell server what formats, encodings, etc users E-Mail prefer HTTP “Accept:” header Telnet e.g. FTP Accept: text/html, text/plain; q=0.5, text/x-dvi; q=0.8 VoIP gives format and preference (“quality”) value q=0: not acceptable q=1: full willingness to accept this type (default) Other headers “Accept-Encoding:” “Accept-Charset:” “Accept-Language:”

CC opensopens TCPTCP connectionconnection toto portport 8080 onon serverserver Introduction C:C: GET GET // HTTP/1.0HTTP/1.0 DNS C:C: Connection: Connection: Keep-AliveKeep-Alive C:C: User-Agent: User-Agent: Mozilla/4.61 Mozilla/4.61 [en][en] (X11;(X11; I;I; LinuxLinux 2.2.102.2.10 i686)i686) E-Mail C:C: Host: Host: localhost:80 localhost:80 HTTP C:C: Accept: Accept: image/gif,image/gif, image/x-xbitmap,image/x-xbitmap, image/jpeg,image/jpeg, image/pjpeg,image/pjpeg, image/png,image/png, */**/* Telnet C:C: Accept-Encoding: Accept-Encoding: gzip gzip C:C: Accept-Language: Accept-Language: enen FTP C:C: Accept-Charset: Accept-Charset: iso-8859-1,*,utf-8 iso-8859-1,*,utf-8 VoIP C:C: S:S: HTTP/1.1 HTTP/1.1 200200 OKOK S:S: Date: Date: Sun,Sun, 0303 JunJun 20012001 16:56:4416:56:44 GMTGMT S:S: Server: Server: Apache/1.3.6Apache/1.3.6 (Unix)(Unix) (SuSE/Linux)(SuSE/Linux) S:S: Last-Modified: Last-Modified: Mon,Mon, 0606 SepSep 19991999 13:37:0213:37:02 GMTGMT S:S: ETag: ETag: "1f042-717-37d3c37e""1f042-717-37d3c37e" S:S: Accept-Ranges: Accept-Ranges: bytesbytes S:S: Content-Length: Content-Length: 138138 S:S: Keep-Alive: Keep-Alive: timeout=15,timeout=15, max=100max=100 S:S: S:S: Connection: Connection: Keep-AliveKeep-Alive S:S:Test <TITLE>Test PagePage S:S: Content-Type: Content-Type: text/htmltext/html S:S: S:S: S:S: bgcolor=#ffffff> S:S: S:S:

Test

Test Page

Page
S:S:This This isis aa testtest page.page. S:S: S:S:

HTTP replace logo State Information

Introduction HTTP is a “stateless” protocol DNS server does not maintain any request related information E-Mail beyond request completion HTTP Telnet “Cookies” can be used to store request related information FTP in browser VoIP described in RFC 2109 “Set-cookie:” header set cookie in browser “Cookie:” header browser sends cookie along with request special cache control required Cookie contains name, value optional: comment, domain, max. age, path, security info, version number

4.5 Telnet replace logo

Introduction RFCs 854 (Telnet), 855 (Options concept) DNS options in RFCs 856–861, 884, 885, 1041, 1091, 1096, E-Mail 1097, 1184, 1372, 1416, 1572 server port: 23 (TCP) HTTP Telnet Provides a local login service remotely FTP Network Virtual Terminal (NVT) specification VoIP Host Direct Connection Telnet Connection Pseudo Telnet Terminal Host Telnet Server Command Client Command User Shell User Shell Terminal Operating System Terminal Operating System Operating System

IP Network

Telnet also allows talking to many ASCII protocol servers on TCP HTTP, SMTP, (FTP), daytime, echo, chargen ... © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-56 Telnet replace logo Network Virtual Terminal

Introduction Terminal and process control are usually vendor specific DNS e.g. end of line by CR (carriage return), LF (line feed) or both E-Mail e.g. program interrupt by Control-C, Escape, Stop... HTTP Network Virtual Terminal defines transmission across the Telnet Internet FTP specific formats are used on client and server side VoIP converted into NVT format and back

Pseudo Telnet Terminal Telnet Server Client Command User Shell Terminal Operating System Operating System IP Network

Client side formatNVT format Server side format

Telnet replace logo Network Virtual Terminal

ASCII control characters Introduction ASCII Dec. Name Operation DNS NUL 0 no operation E-Mail BEL 7 bell audible/visible signal HTTP BS 8 backspace move left one character position Telnet HT 9 hor. Tab move right to next horizontal tabulator position LF 10 line feed move vertically down to the next line FTP VT 11 vert. Tab move down to next vertical tabulator position VoIP FF 12 form feed move to top of next page CR 13 carriage return move to left margin of current line other ignored NVT signals Signal Operation IP Interrupt Process: terminate running program AO Abort Output: discard any buffered output AYT Are You There: request response from server EC Erase Character: delete the previous character EL Erase Line: entirely delete the current line SYNCH Synchronize: clear data until TCP urgent point but interpret commands (concept) BRK Break: break key or attention signal

IAC (interpret as control) character reserved as escape Introduction sequence DNS indicate that a control octet follows E-Mail Command Dec. Function ice iiff nneeeedededd HTTP Seenndd IIAACC ttwwice S ata Telnet IAC 255 interpret next octet as command 8-bbiitt oocctteett ddata EOR 239 end of record iinn 8- FTP SE 240 end of option subnegotiation VoIP NOP 241 no operation DMARK 242 data stream portion of a SYNCH signal (with TCP Urgent notification) BRK 243 NVT Break signal IP 244 NVT Interrupt Process signal MARRKK iinn AO 245 NVT Abort Output signal IACC IIPP IIAACC DDMA SSeenndd IA interrrurupptt AYT 246 NVT Are You There signal rgenntt mmooddee ttoo inte TTCCPP uurge ” EC 247 NVT Erase Character signal s “oouutt ooff bbaanndd” EL 248 NVT Erase Line signal aa pprroocceesss “ GA 249 Go Ahead SB 250 start of option subnegotiation ent ++ DDMMAARRKK WILL 251 agree to perform specified option TTCCPP UUrrggent WON’T 252 refuse to perform specified option == ““ssyynncchh”” DO 253 allow specified option DON’T 254 deny to perform specified option requested

Telnet replace logo Options

Introduction DNS Telnet options are negotiated between client and server E-Mail symmetric negotiation (client or server can make a request) HTTP extendible (anyone can refuse to use or let use unknown Telnet options) FTP VoIP Negotiation: WILL/WONT, DO/DONT two-way negotiation do not acknowledge options already in use

A->B: WILL x A wants to use option x B->A: DO x (ok) or DONT x (not ok) A->B: DO x A wants B to use option x B->A: WILL x (ok) or WONT x (not ok)

Introduction Option Code RFC Explanation DNS Transmit Binary 0 856 Change transmission to 8-bit binary E-Mail HTTP Echo 1 857 process echoes the data it receives Telnet Suppress-GA 3 858 do not send Go-Ahead signal after data FTP Status 5 859 request the status of a Telnet Option VoIP Timing-Mark 6 860 request timing mark to be inserted in return stream Terminal-Type 24 884 terminal type information to allow programs to use advanced terminal features (cursor positioning, optimisation, colors) End-of-Record 25 885 terminate data with EOR code Linemode 34 1116 send complete line after local editing (instead of sending single characters)

Chapter 4: replace logo Applications and Application Layer Protocols

Introduction File Transfer Protocol DNS RFCs 959, 2228, 2577, 2585 E-Mail server ports: 20 for data and 21 for control (TCP) HTTP Telnet gives access to files on remote computers FTP file transfer: interactive access VoIP get, put, list, modify attributes no direct on-line file sharing authentication data format specification representation type: binary, ASCII, EBCDIC, local file structure: file, record structure, page structure transfer mode: stream, block, compressed virtual file system basic operation modes and file name support translation of commands on client and server machines

FTP replace logo Concept

Introduction Separate connections for control and data DNS Control Connection E-Mail defines “ftp session” HTTP coordinates data connections and their port numbers Telnet uses Telnet NVT abstraction FTP Data Connections VoIP created dynamically to transfer data / files on-the-fly format conversion (binary “image”, ASCII, EBCDIC, “local”) Many systems offer a very simple user interface

Port FTP Client FTP Server User 21 Server User Agent IP Control File Transfer Network 20 File Transfer File System File System Agent Agent

Introduction Access Control commands DNS USER, PASS, ACCT, CWD, CDUP, SMNT, REIN, QUIT E-Mail Transfer Parameter commands HTTP PORT, PASV, TYPE, STRU, MODE Telnet FTP Service commands FTP RETR, STOR, STOU, APPE, ALLO, REST, RNFR, RNTO, VoIP ABOR, DELE, RMD, MKD, PWD, LIST, NLST, SITE, SYST, STAT, HELP, NOOP Reply codes indicate success status

Default data port client side: same as control connection server side: port 20 non-default data ports can be negotiated PORT command: client side specifies different port PASV command: client makes server specify different port and listen there Closing data connection implies end of file

FTP replace logo Example Conversation

Introduction DNS CCestablishes establishes controlcontrol connectionconnection toto S,S, portport 21;21; clientclient side:side: portport U U S: 220 ftp server ready E-Mail S: 220 ftp server ready C: USER joachim HTTP C: USER joachim S:S: 331 331 UserUser ok,ok, needneed passwordpassword Telnet C:C: PASS PASS topsecret topsecret FTP S:S: 230 230 UserUser joachim joachim logged logged inin VoIP C:C: RETR RETR index.htmlindex.html S:S: 150 150 filefile statusstatus okok,, openingopening datadata connectionconnection SSopens opens connectionconnection fromfrom portport 2020 toto clientclient portport U,U, sendssends file,file, closescloses connectionconnection S:S: 226 226 successfullysuccessfully transfered transfered 2307 2307 bytes,bytes, closingclosing datadata connectionconnection C:C: TYPE TYPE II S:S: 200 200 CommandCommand OKOK C:C: STOR STOR IPNA-4-bw-4.pdfIPNA-4-bw-4.pdf S:S: 550 550 AccessAccess DeniedDenied C:C: QUIT QUIT SScloses closes allall connectionsconnections

4.7 Voice over IP / IP Telephony replace logo

Introduction Two main sets of standards: DNS E-Mail ITU-T and IETF defined H.323 HTTP multimedia transport in general Telnet several protocols for different functions FTP VoIP Terminal Terminal IP Phone Packet Voice H.323 SIP Gate- keeper

Session Initiation Protocol SIP simpler protocol ASCII messages defined by IETF

Introduction the original signal is analog DNS E-Mail Digitize analog signal (PCM) HTTP e.g. 8 bit per sample, 8ksamples/s Telnet FTP collect blocks of data VoIP Packet Voice encode to remove redundancy / H.323 SIP irrelevance ADPCM, FFT/DCT quantization, ...

Put resulting data into data packets add RTP, UDP, IP headers

transmit packets through IP network

Reverse process at receiver side

ADPCM Adaptive Differential PCM FFT Fast Fourier Transform DCT Discrete Cosine Transformation PCM Pulse Code Modulation

Packetized Voice replace logo Data Rates

ACELP Algebraic CELP ADPCM Adaptive Differential PCM Introduction Tradeoff between efficiency CELP Code Excited Linear Prediction DNS CS-CELP Conjugate Structure CELP and delay DCT Discrete Cosine E-Mail Transformation large blocks cause large delay FFT Fast Fourier Transform HTTP large blocks have lower overhead MIPS Million Instructions per Second Telnet MLQ Maximum Likelihood (RTP, UDP, IP headers) Quantization FTP large blocks allow better MOS Mean Opinion Score MP-MLQ Multi Pulse MLQ VoIP compression PCM Pulse Code Modulation Packet Voice H.323 SIP Data Rates, without silence suppression Net Framing Quality Codec Standard Method Rate* +Lookahead Complexity nd evell raratteess ddeeppeend (kbit/s) (ms) (MOS) (MIPS) IIPP lleve k greggaattiioonn bblolocck oonn aagggre G.711a PCM 64 0+0 4.4 0.2 sisizzee G.726 ADPCM 32 0.125+0 4.1 2 G.729A CS-ACELP 8 10+5 4.0 20 G.729E CS-ACELP 11.8 >4.4 >20 G.723.1 MP-MLQ 6.3 30+7.5 3.6 16 G.723.1 ACELP 5.3 30+7.5 3.4 16 *above RTP © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-70 4.7.2 H.323 replace logo Protocol Overview

Introduction DNS System Control Media Transport E-Mail Audio/Video Data HTTP Telnet RAS Call Media Audio/ Audio/ Audio/ Control Control Channel Video Video Video FTP Control Stream Codec Stream VoIP Control Control Packet Voice H.323 G.711... H.323 SIP H.261...

H.225 H.225 H.225/ H.225 H.225 Q.931 H.245 RTCP RTP RTCP

Unreliable Reliable Reliable Unreliable Unreliable Reliable Transport (e.g. UDP) (e.g. TCP) (e.g. TCP) (e.g. UDP) (e.g. UDP) (e.g. TCP)

RAS Registration, Admission and Status RTCP Real Time Transport Control Protocol TCP Transmission Control Protocol UDP User Datagram Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-71

H.323 replace logo Additional Standards

Introduction DNS H.450: additional features E-Mail H.450.1: common protocol for service / features support HTTP H.450.2ff: description of features, Telnet e.g. call transfer, hold FTP like private branch exchange (PBX) features VoIP Packet Voice H.323 SIP H.235: security

H.246: interworking with circuit switched networks

H.248: Media Gateway Control (Megaco)

Introduction DNS Phases of a connection E-Mail HTTP Telnet 0. Initialization FTP 1. Gatekeeper admission VoIP Packet Voice 2. Call Control Signalling H.323 SIP ainn 3. Negotiation and Configuration TThhiiss iiss tthhee mmai f telleepphhoonnyy!! 4. Media data exchange ppuurrppoossee oof te 5. Re-negotiation and administration 6. End

H.323 replace logo Connection Set-up

H.323 Terminal A H.323 Gatekeeper H.323 Terminal B Introduction ARQ DNS RAS H.225 ACF E-Mail Setup HTTP Setup Call Call Proceeding Telnet Call Proceeding Control FTP ARQ H.225/ VoIP Q.931 ACF Packet Voice Connect H.323 Connect SIP TerminalCapabilitySet Media TerminalCapabilitySet Channel TerminalCapabilitySetAck TerminalCapabilitySetAck Control OpenLogicalChannel H.245 OpenLogicalChannel OpenLogicalChannelAck OpenLogicalChannelAck RTP/RTCP

ARQ Admission Request RTCP Real Time Transport ACF Admission Confirm Control Protocol RAS Registration, Admission and Status RTP Real Time Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-74 H.323 replace logo Connection Release initiated by Gatekeeper

H.323 Terminal A H.323 Gatekeeper H.323 Terminal B Introduction DNS RAS DRQ E-Mail H.225 Call EndSessionCommand HTTP EndSessionCommand Control Telnet H.225/ EndSessionCommand FTP EndSessionCommand Q.931 VoIP Packet Voice Media ReleaseComplete ReleaseComplete H.323 Channel SIP DCF Control DRQ H.245 DCF

DRQ Disengage Request DCF Disengage Confirm RAS Registration, Admission and Status © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-75

H.323 Additional Message Sequences replace logo Initialization (Phase 0)

H.323 Terminal A H.323 Gatekeeper(s) H.323 Terminal B Introduction GRQ DNS RAS GCF E-Mail H.225 HTTP Find GRQ Telnet Gatekeeper GCF FTP VoIP Packet Voice RAS RRQ H.323 RCF SIP H.225

RRQ Registration Request GRQ Gatekeeper Request RCF Registration Confirm GCF Gatekeeper Confirm RAS Registration, Admission and Status © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-76 H.323 Additional Message Sequences replace logo Bandwidth re-negotiation initiated by user

H.323 Terminal A H.323 Gatekeeper H.323 Terminal B Introduction BRQ DNS RAS BCF E-Mail H.225 CloseLogicalChannel HTTP CloseLogicalChannel OpenLogicalChannel Telnet OpenLogicalChannel FTP Media Channel BRQ VoIP Packet Voice Control BCF H.323 H.245 SIP OpenLogicalChannelAck OpenLogicalChannelAck

BRQ Bandwidth Change Request BCF Bandwidth Change Confirm RAS Registration, Admission and Status © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-77

4.7.3 SIP replace logo Complete Call

Introduction UACProxy UAC DNS INVITE E-Mail INVITE HTTP SIP OK Telnet OK FTP ACK VoIP Packet Voice H.323 SIP RTP

BYE

UAC User Agent Client ACK Acknowledge SIP Session Initiation Protocol RTP Real Time Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-78 SIP replace logo Canceled Invite

Introduction UACProxy UAC DNS INVITE E-Mail INVITE HTTP SIP CANCEL Telnet CANCEL FTP VoIP Request Terminated Packet Voice Request Terminated H.323 OK SIP OK

ACK

UAC User Agent Client ACK Acknowledge SIP Session Initiation Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 4 Edition Summer 2004 4-79

Questions replace logo

Introduction 4.1 Determine the name and address of the authoritative nameserver DNS for “ei.uni-stuttgart.de” using “nslookup” or “dig”. E-Mail 4.2 Use nslookup to determine the host name for IP address HTTP 129.69.1.76 . Telnet 4.3 What hosts are mail exchangers for “jcho.de”? FTP 4.4 Write a simple SMTP client and test if it can deliver a mail VoIP message. (Handle only the “good” case.)

Questions 4.5 Telnet to a Web server (port 80) and retrieve a Web page. Can you make the server not close the connection immediately? How long does it take until the server closes the connection? 4.6 Play with the Web server from Section 4.1.4.

4.7 What is Network Address Translation (NAT)? 4.8 What is the Hurst Parameter? 4.9 How would you measure Internet quality? 4.10 What is the difference between the IntServ and DiffServ concepts?

Information and Communication Networks

IP Based Networks and Applications Chapter 5: Network Architectures

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

The Internet 5.1 The Internet Local IP Networks 5.2 Local IP Networks Intranets Residential Access 5.3 Intranets Voice Carriers 5.3.1 Network Address Translation (NAT) Mobile Networks 5.3.2 Virtual Private Networks (VPN) 5.3.3 Remote LAN Access (RLA) Overlay Networks 5.4 Residential Access 5.5 Voice Carrier Networks 5.6 Mobile Networks 5.6.1 Mobility Support 5.6.2 GPRS 5.6.3 Header Compression 5.6.4 TCP and Packet Loss 5.7 Overlay Networks 5.7.1 General View 5.7.2 Building Overlays with P2P mechanisms

5.1 The Internet replace logo

The Internet Local IP Networks Worldwide connectivity Intranets ISPs connect private and business users Residential Access private: mostly dial-up connections Voice Carriers business: mostly always-on connections Mobile Networks plus: academic networks (part of the Internet) Overlay Networks

Structure large ISPs have their own world-wide backbone networks (leased lines interconnecting routers) smaller ISPs have peering agreements with large ISPs to transport wide area traffic most traffic to or from outside networks efforts (e.g. portals) to keep more traffic within own network

see Chapter 1

The Internet Local IP Networks IP is used outside the Internet Intranets other “IP Networks” Residential Access Voice Carriers Reasons Mobile Networks ubiquitous availability of IP in end systems Overlay Networks IP network components (routers) offer high throughput per $ simple configuration and cheap subnetwork components (hubs, switches)

Integration of services e.g. voice and data bandwidth sharing between traffic types save on operating personnel by unified network technology → IP is being introduced into “classical” telecommunication networks

Chapter 5: replace logo Network Architectures

The Internet Local IP Networks There are additional applications in local networks Intranets not routed into The Internet Residential Access Host configuration services Voice Carriers DHCP, TFTP, bootp Mobile Networks File services Overlay Networks access to remote file systems on local computer NFS, Windows(r) file sharing backup services Print services Graphical remote terminal access (X11) Specific additional applications SAP, peoplesoft, groupware (Lotus notes, MS exchange...) directories, databases authentication services

bootp replace logo

The Internet Local IP Networks Bootstrap Protocol [RFCs 951, 2132] Intranets Residential Access replacement for RARP Voice Carriers uses UDP/IP for communication Mobile Networks ports 67 (server) and 68 (client) Overlay Networks uses limited IP broadcast (255.255.255.255) before IP address, network and network mask are known returns IP address plus further information IP address, boot file name and server optionally: server addresses for time, DNS, lpr servers host name boot file size

ARP Address Resolution Protocol DNS Domain Name System NFS Network File System RARP Reverse ARP TFTP Trivial File Transfer Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 5 Edition Summer 2004 5-8 bootp replace logo Message Format

The Internet Local IP Networks 08162431 Intranets OP HTYPE HLEN hops Residential Access Transaction ID Voice Carriers seconds unused Mobile Networks Client IP Address Overlay Networks your IP Address Server IP Address Router IP Address Client Hardware Address . . . (16 oct) Server Host Name . . . (64 oct) Boot File Name . . . (128 oct) Vendor Specific Area (64 oct)

bootp Message Fields replace logo

The Internet Local IP Networks same format for client and server messages Intranets client specifies field values as far as possible Residential Access other fields set to zero Voice Carriers OP (1=request, 2=reply) Mobile Networks Overlay Networks HTYPE, HLEN: Hardware type and address length e.g. Ethernet: HTYPE=1, HLEN=6 HOPS=0 (unless forwarded by server) seconds = number of seconds since client started to boot ... your IP Address: client IP address from server if client IP address was set to 0 boot file name name of boot file to be loaded later, e.g. using tftp or NFS

The Internet Local IP Networks Dynamic Host Configuration Protocol [RFC 2131] Intranets Residential Access extension of bootp Voice Carriers more information in returned message e.g. subnet mask Mobile Networks optional automatic or dynamic IP address assignment Overlay Networks server selects IP address from a pool of free addresses multi-step procedure limited-time lease of an IP address to a client client wishes and server grants lease duration client requests renewal after 50% of lease duration early lease termination is possible static address assignment with DHCP server knows client’s hardware address (configured by network manager) grants very long (or infinite) lease of address

Others replace logo

The Internet non-IP based protocols in LANs Local IP Networks Intranets Residential Access netbios / netbeui ® ® Voice Carriers Microsoft Windows networks Mobile Networks may be based on IP (attention: sometimes using multicast / Overlay Networks broadcast!)

Appletalk

happtteerr 11!! Bridging protocols rreemmeemmbbeerr CCha

ISO OSI CLNP CLNP Connectionless Network Protocol ISO International Organisation DECnet, LAT e itt for Standardisation w siitteess ssttiillll uusse i LAT Local Access Terminal / aa ffeew s Local Area Transport OSI Open Systems Interconnection © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 5 Edition Summer 2004 5-12 Chapter 5: replace logo Network Architectures

5.3 Intranets replace logo

The Internet Internal IP networks (e.g. of a company) Local IP Networks full internal IP connectivity Intranets often with internal DNS name space, DNS servers etc Residential Access often interconnecting multiple sites in the world Voice Carriers external connectivity to Internet Mobile Networks via NAT, application proxies, firewalls, gateways Overlay Networks

often with private address range (e.g. 10.0.0.0 network) or duplicate of a valid Internet address range (connectivity problems!) problems with company mergers!

Internal services usually not exported to external world exported services with access limitation → “Extranets”

The Internet whole private address space “hides” behind one public IP Local IP Networks address Intranets translation of port numbers allows multiple internal hosts to Residential Access communicate comppuuttee ththee IIPP Voice Carriers savings in global IP addresses rreecom ! derr cchheecckksusumm! Mobile Networks hheeaade issues with application layer protocols Overlay Networks if they talk about IP addresses or port numbers e.g. FTP, H.323 resolved by proxy servers or application awareness

Intranet NAT Internet

Private Private NAT NAT Internet Internet IP Addr. Port IP Addr. Port IP Addr. Port 10.1.0.3 1030 193.5.7.17 18001 129.69.1.78 80 10.20.3.2 1030 193.5.7.17 18002 129.69.1.78 80 10.1.0.3 1031 193.5.7.17 18007 203.53.153.24 23 10.67.23.1 25 193.5.7.17 19213 131.58.243.3 25

5.3.2 Virtual Private Networks (VPN) replace logo

The Internet provide a private network using public IP network Local IP Networks infrastructure Intranets IP tunneling Residential Access encryption Voice Carriers Mobile Networks Overlay Networks VPN applications between different sites of an enterprise site-to-site VPN private network addresses can be tunneled over a public network tunnel works just like a leased line for remote access allows remote access to the Intranet for providing an “Extranet” allows outside access to a part of an Intranet

The Internet Local IP Networks Dial-up access to an Intranet Intranets for teleworking Residential Access Voice Carriers Mobile Networks Private modem pool and access server within Intranet Overlay Networks long-distance dial-up connections information security relies on telephone network

VPN based access use IP tunnel over the Internet or from a VPN provider encryption of data in tunnel ensures information security world-wide ISP presence allows local calls for dial-up connections

Chapter 5: replace logo Network Architectures

ISPs offer dial-up or “always-on” access to the Internet The Internet Local IP Networks Dial-up access: Remote Access Service (RAS) Intranets circuit switched connection between customer and Point of Presence (PoP) Residential Access via telephone / ISDN network Voice Carriers some ISPs provide dial-up access over xDSL lines Mobile Networks Overlay Networks Issues User / account authentification, authorization accounting AAA dynamic host configuration Protocol transport of IP packets AAAS HC Voice NAS Network Internet M MP Link Layer Protocol AAA Authentication, Authorization, Accounting M Modem AAAS AAA Server MP Modem Pool HC Home Computer NAS Network Access Server ISP Internet Service Provider xDSL Digital Subscriber Line © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 5 Edition Summer 2004 5-19

RAS replace logo Link Layer Protocols

The Internet Serial Line IP Protocol (SLIP) [RFC 1055] or Local IP Networks Intranets Point to Point Protocol (PPP) Residential Access RFC 1661, one additional RFC per lower layer technology Voice Carriers Transmission of IP packets over serial point to point links Mobile Networks packet framing / delineation (HDLC-like) Overlay Networks adds 8 octets overhead per packet optional: header compression (see 5.6.3)

1111 n 2 1 Flag Address Control Protocol data ... Checksum Flag

Link Control Protocol (LCP) in PPP link establishment, configuration and management Network Control Protocols (NCP) in PPP IP address assignment

The Internet Local IP Networks RADIUS [RFC2138] Intranets Residential Access Voice Carriers Authentication Mobile Networks Who is calling? Overlay Networks Authorization What is this user allowed to do? What Link Layer protocol can they use? Configuration of Link Layer parameters Accounting collect data on usage time, bytes transfered, etc

new development: DIAMETER

Chapter 5: replace logo Network Architectures

The Internet Local IP Networks currently more attractive in enterprise than in public networks Intranets ubiquitous high-performance data networks Residential Access bandwidth sharing between voice and data Voice Carriers DiffServ can be introduced in an enterprise network Mobile Networks voice lines and separate voice switching equipment can be Overlay Networks saved high share of local traffic fewer media gateways needed than in public network scenarios POTS/ISDN Terminal Media Switch IP Phone Gateway Circuit IP Network Switched Network classical telephone

Gate- Media Gateway Controller keeper + Signalling Gateway

Gateways replace logo

The Internet Media Gateway Local IP Networks conversion between voice formats Intranets using DSPs Residential Access traditional network Voice Carriers PCM voice Mobile Networks ISDN Overlay Networks IP network G.711, G.723, etc for voice coding see Sec. 4.5.1 Media Gateway Controller (MGC) conversion between IP and POTS/ISDN signalling IP side: H.323, SIP POTS side: SS7, PBX protocols control of media gateway (e.g. MEGACO) PBX Private Branch Exchange DSP Digital Signal Processor PCM Pulse Code Modulation ISDN Integrated Services Digital Network POTS Plain Old Telephony Service MEGACO Media Gateway Control Protocol SIP Session Initiation Protocol MGC Media Gateway Controller SS7 Signalling System #7 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 5 Edition Summer 2004 5-24 Chapter 5: replace logo Network Architectures

5.6 Mobile Networks replace logo 5.6.1 Mobility Support

The Internet Mobile IP Local IP Networks RFCs 2002, 2005, 2006 Intranets Residential Access Voice Carriers Difference between wireless technology and mobility! Mobile Networks wireless technology: communicate while moving Overlay Networks wire bound technology: plug into a new network and continue working

Mobile IP specifies mobility support (more or less) independent of access technology transparent support (independent of communication partners) for IPv4 mobility across the Internet (scalable in terms of distance)

advertisement / broadcast based forwarding management for infrequent changes of location

mobility of mobile node MN supported The Internet Local IP Networks no need for communication partner (Correspondent Node, Intranets CN) to know about this Residential Access CN still sends packets to home address of MN Voice Carriers Mobile Networks minimum requirement: Home Agent (HA) Overlay Networks MN can act as Foreign Agent (FA) 1 R CN Home Network Internet 4 MN HA 2 Foreign R R FA Network 3 MN CN Correspondent Node FA Foreign Agent HA Home Agent MN Mobile Node R Router © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 5 Edition Summer 2004 5-27

Mobile IP (2) replace logo

The Internet Local IP Networks Mobile node connects to foreign network MN obtains IP address in foreign network (e.g. via dhcp) Intranets MN locates foreign agent Residential Access IPsec tunnel established from Home Agent (HA) Voice Carriers to Foreign Agent (FA) Mobile Networks IP address of FA is called “care-of” address Overlay Networks packets to the mobile node reach the home network via standard IP routing 1 are intercepted by the home agent home agent forwards packet to care-of address within tunnel 2 foreign agent forwards packet to mobile node (no tunnel) 3 packets from the mobile node are sent via standard IP routing to the corresponding node (“triangular routing”) 4 or are sent to the foreign agent forwarded within reverse tunnel to home agent sent to correspondent node by home agent

General Packet Radio Service The Internet provide a packet service extension to GSM mobile networks Local IP Networks Intranets Protocol Stack: Residential Access Application Voice Carriers IP/X.25 IP/X.25 Mobile Networks Relay Overlay Networks SNDCP SNDCP GTP GTP LLC LLC UDP / UDP / Relay TCP* TCP* RLC RLC BSSGP BSSGP IP IP Network Network MAC MAC L2 L2 Service Service GSM RF GSM RF L1bis L1bis L1 L1 Mobile Station Base Station SGSN GGSN * TCP for X.25, UDP for IP

BSSGP Base Station System GPRS Protocol LLC Logical Link Control GGSN Gateway GPRS Support Node MAC Media Access Control GPRS General Packet Radio Service RLC Radio Link Control GSM Global System for Mobile Communication SGSN Serving GPRS Support Node GTP GPRS Tunnelling Protocol SNDCP Subnetwork Dependent Convergence Prot. © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 5 Edition Summer 2004 5-29

5.6.3 Header Compression replace logo

IETF Working Group on “Robust Header Compression” The Internet (rohc) Local IP Networks http://www.ietf.org/html.charters/rohc-charter.html Intranets Residential Access “old” header compression schemes (RFCs 1144, 2508) Voice Carriers remove redundancy from IP, UDP, TCP headers Mobile Networks new header compression schemes (rohc working group) Overlay Networks especially for wireless links compress RTP and frequently used TCP options (SACK, timestamps) robust to high error rates / packet (frame) loss robust to long round-trip times unidirectional links (?) requirements semantic identity of header after compression and decompression perform well even when the end-to-end path involves multiple wireless links support IPv4 and IPv6

The Internet Local IP Networks some TCP/IP header fields do not change during a Intranets connection Residential Access IP version, header length, TOS, fragmentation, TTL, protocol, Voice Carriers source address, destination address Mobile Networks TCP source and destination ports, data offset, reserved bits, Overlay Networks flags: ACK, RST, SYN, FIN

spend capacity according to information contents in fields TCP FIN flag (95% “0”, 5% “1”) small set of frequent payload sizes quite fixed size of acknowledgements

headers can be compressed down to a few bits

5.6.4 TCP and Packet Loss replace logo

The Internet TCP congestion control Local IP Networks assumes packet loss (missing ACK) is a sign of congestion Intranets reduces sending rate through congestion window Residential Access Voice Carriers Problems in wireless networks: Mobile Networks Additional packet loss due to Overlay Networks transmission errors on wireless links phases of bad transmission -> multiple packets lost -> slow start communication pause (or delay variation) due to handoffs / handovers

losses are independent of congestion state “wireless TCP” should not necessarily reduce its rate in those cases at least not fall back to slow start after packets lost due to transmission errors

The Internet Local IP Networks reduce wireless transmission errors Intranets use fast ARQ on wireless links Residential Access alternative: intercept transport protocol, create artificial ACKs Voice Carriers etc Mobile Networks loss of end-to-end semantics of TCP Overlay Networks

reduce handoff latency overlapping cells additional fast retransmission techniques immediately after a new cell is reached

Chapter 5: replace logo Network Architectures

The Internet overlay networks Local IP Networks use an IP network (the Internet) transparently Intranets enable their own routing by sending packets from one node Residential Access to another Voice Carriers use tunneling or application layer mechanisms to direct Mobile Networks packets Overlay Networks set-up of overlay: automatic or configured

often used to work around shortcomings of the Internet multicast hierarchical structure temporal connectivity some hosts and networks are not permanently connected anonymity bandwidth provisioning

Overlay Networks replace logo Examples

Virtual Private Network (VPN) The Internet virtual lines created by tunneling Local IP Networks security offered by tunnel encryption (see Chapter 9) Intranets DNS and e-mail Residential Access virtual naming hierarchy created on top of the Internet Voice Carriers DNS hierarchy does not follow Internet topology nor IP address Mobile Networks hierarchy Overlay Networks e-mail servers can store e-mails while parts of the network are unavailable multicast duplication of packets / information on application layer group management on application layer “peer-to-peer” services group management virtual topology support for distributed searching QoS overlays measure available bandwidth between hosts send traffic from host to host on best bandwidth path

The Internet Different aspects of Peer-to-Peer (P2P) mechanisms Local IP Networks peer-to-peer overlay control Intranets locate the IP address of communication partners within the Residential Access same p2p community Voice Carriers search for contents through the databases of these partners Mobile Networks limited search -> everyone asks n (e.g. 5) of their neighbors Overlay Networks good scaling for replicated contents self-management of overlay structures nodes come and go nodes can change their IP addresses little manual management effort, but a lot of control traffic peer-to-peer communication this is the default mode of communication on the Internet ☺ everyone can act as a server on an IP network the difficulty is in finding the right server -> see overlay control

P2P search replace logo

The Internet application layer multicast for searching Local IP Networks direct peer-to-peer connection for download Intranets Residential Access “looking for file x” Voice Carriers “give me file x” Mobile Networks download Overlay Networks

“I’ve got file x”

real (IP) network topology is different from overlay topology

IntroductionThe Internet 5.1 Which ISP networks does a packet pass on the way from DNSLocal IP Networks University of Stuttgart to www.jcho.de? E-MailIntranets 5.2 Read about NFS. Why is it not suitable for wide area HTTPResidential Access applications? TelnetVoice Carriers 5.3 Use ping to find out the distribution of packet delays to a FTPMobile Networks transatlantic destination. Are these delays suitable for real-time VoIP applications? Questions Questions 5.4 What is the difference in structure and location protocols for the Napster, Gnutella and Kazaa systems?

Information and Communication Networks

IP Based Networks and Applications Chapter 6: Statistics and Performance

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Chapter 6 6.1 Introduction Introduction 6.1.1 Basic Statistics Web Statistics 6.1.2 Classical Models and Results Self-Similarity Simulations 6.2 Web Statistics 6.2.1 TCP Effects 6.2.2 Heavy-Tailed Distributions 6.3 Long-Range Dependence and Self-Similarity 6.4 Issues with Simulations

6.1 Introduction replace logo 6.1.1 Basic Statistics

Chapter 6 Introduction Basic Statistics Measurement takes n samples Xi Classical Results e.g. service times, interarrival times Web Statistics Samples are described by characteristic values Self-Similarity

Simulations Mean Value = 1 E[X ] n ∑ X i

2 empirical Variance = 1 − VAR[X ] n−1 ∑ (X i E[X ]) = Coefficient of Variation cX VAR[X ] / E[X ]

Confidence Interval describes trustworthiness of characteristic value derived from batch evaluations often just taken as proportional to variance

Chapter 6 Introduction Basic Statistics mathematical concept instead of real samples Classical Results described by statistical characteristics Web Statistics distribution Self-Similarity correlation Simulations

Characteristics of distributions Expectation Variance

Stochastic Process

Distributions replace logo

Chapter 6 Introduction Basic Statistics describe probability for certain values Classical Results Web Statistics Self-Similarity discrete random variables Simulations X = x examples: number of downloads per session number of active users

continuous random variables X ∈ [x,x+dx] examples: session duration packet interarrival time

Chapter 6 Probability Distribution, 1 Introduction Probability Mass Function 0.8 Basic Statistics = = Classical Results p (x) P{X x} X 0.6 Web Statistics 0.4 Self-Similarity Simulations 0.2

0 0 1 2 3 4 5 x

(Cumulative) 1

Distribution Function 0.8 = ≤ FX (x) P{X x} 0.6 DF CDF Complementary (Cumulative) 0.4

Distribution Function 0.2 = > = − CX (x) P{X x} 1 FX (x) 0 0 1 2 3 4 5 x

Continuous Distributions replace logo

Chapter 6 (Cumulative) Distribution 1 Introduction Function 0.8 Basic Statistics = ≤ Classical Results FX (x) P{X x} 0.6 Web Statistics DF CDF Complementary (Cumulative) 0.4 Self-Similarity Distribution Function 0.2 Simulations = > = − CX (x) P{X x} 1 FX (x) 0 0 2 4 6 8 10 x

Probability Density Function 1 = d ≤ 0.8 f X (x) P{X x} dx 0.6

0.4

0.2

0 0 2 4 6 8 10 x

Chapter 6 Introduction Exponential (negative exponential) Basic Statistics = λ −λx = −λx Classical Results f (x) e C(x) e Web Statistics Hyperexponential Self-Similarity −λ −λ −λ −λ f (x) = p λ e 1x + p λ e 2 x C(x) = p e 1x + p e 2 x Simulations 1 1 2 2 1 2 Lognormal 1 1  (ln(x) − µ)2  f (x) = exp−   2  2πσ 2 x  2σ  Pareto = α α −α −1 = α f (x) x0 x C(x) (x0 / x)

Weibull α α f (x) = αβ−α xα−1e−(x /β) C(x) = e−(x /β) Gamma f (x) = (1/ Γ(α))β−α xα−1e− x /β

6.1.2 Classical Models and Results replace logo

Chapter 6 performance characteristics of stochastic models differ Introduction Basic Statistics significantly from deterministic service Classical Results increased variation (generally) decreases performance Web Statistics increased queue lengths Self-Similarity longer waiting time Simulations higher loss probability

simple “classical” models M/G/1 waiting system M/G/n-0 loss system no buffer space n Servers General Service Time Distribution (but independent) Poisson Arrivals

λ Chapter 6 Poisson FIFO Server Arrival Rate Arrivals Buffer Introduction Mean Service Time h Basic Statistics Classical Results M G coefficient of variation c λ S Web Statistics h Relative Offered Load ρ = λ h Self-Similarity Simulations Expected Waiting Time 10 (Pollaczek-Khintchine) 9 8 cs=0 2 cs=1 ρ + 7 (1 cS ) cs=2 = h 6

E[W ] h ]/ − ρ 5 2(1 ) W 4 E[ ρ ρ 3 VVaarriiaannccee proportional to /(1- ) s 2 2 iinnccrreeaassees proportional to (1+ c ) me S 1 wwaaiittiinngg ttiime 0 0 0.2 0.4 0.6 0.8 1 ρ

FIFO First In First Out © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-11

M/G/n-0 Loss System replace logo

Chapter 6 n Servers Arrival Rate λ Introduction Basic Statistics Poisson G Mean Service Time h Classical Results Arrivals Offered Load A = λ h Web Statistics M G Pseudo unit “Erlang” Self-Similarity λ

Simulations ... Relative Offered Load ρ = λ h / n G h

1 Loss Probability An B = n! 0.1 Ai calee B 0.01 y off SScal ∑ i! EEccoonnoommy o

n=1 0.001 n=10 B→1 for A→∞ (ρ→∞) n=100

independent of 0.0001 0.01 0.1 1 10 service time distribution ρ

6.2 Web Statistics replace logo 6.2.1 TCP Effects: Packet Sizes

Chapter 6 1 Introduction Web Statistics EthernetEthernet MTUMTU TCP Effects 0.8 al foorrHHTTTTPP Heavy Tails ttyyppiiccal f ET rreeqquueessttss Self-Similarity GGET Simulations 0.6 SYNSYN MTU/MSSMTU/MSS LimitsLimits FINFIN 0.4 down ACKACK up

0.2

0 0 200 400 600 800 1000 1200 1400 1600 Packet Size

Data: ADSL Münster, incl. Ethernet overhead © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-14 Bit Rate Symmetry for Web Access replace logo

Chapter 6 Introduction Web Statistics TCP Effects l“ Coonnnneeccttiioonnss Heavy Tails „„SSmmaalll“ C e symmmmeettrriicc Self-Similarity aarree mmoorre sy Simulations epeennddeenntt RReessuulltt iiss iinnddep peeedd ooff nneettwwoorrkk sspe

Data: ADSL Münster © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-15

Bit Rate Symmetry (2) replace logo

TCPTCP CharacteristicsCharacteristics Chapter 6 Connection overhead Introduction + mean GET request Web Statistics TCP Effects Acks Heavy Tails vu ≈ 580B +α ⋅ 60B Data packets Self-Similarity vd vd 1500B Simulations Ratio of Acks to data packets

Data: ADSL Münster © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-16 6.2.2 Heavy Tailed Distributions replace logo

Chapter 6 vy TTaaiill““ 1e+0 „„HHeeaavy Introduction Web Statistics TCP Effects α =1 infiniteinfinite expectationexpectation 1e-1 Heavy Tails infiniteinfinite variancevariance Self-Similarity Simulations 1e-2 α = 2

−α 1e-3 P[X > x] ~ x

1e-4 finitefinite expectationexpectation finitefinite expectationexpectation finitefinite variancevariance infiniteinfinite variancevariance 1e-5 100 1 k 10 k 100 k 1 M 10 M Item Size in Bytes

Number of GET Requests per Flow replace logo

Chapter 6 1 lowss ggeett Introduction 1100%% ooff aallll fflow 0 elleemmeennttss Web Statistics moorree tthhaann 440 e 0.1 m erveerr TCP Effects rom tthhee ssaammee sserv Heavy Tails ffrom Self-Similarity 0.01 Simulations

0.001

Clt. Sess. 0.0001 H2H Flow One Click P2P Flow Complementary Distribution Function 1e-005 0.1 1 10 100 1000 10000 100000 ve Number of GET Requests onnneeccttiioonnss sseerrve 3300%% ooff aallll ccon an oonnee rreeqquueesstt P2P Port to Port mmoorree tthhan H2H Host to Host Clt. Client Data: ADSL Münster Timeout 10min © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-18 Flow Volumes replace logo

Chapter 6 1 Introduction Web Statistics TCP Effects 0.1 Heavy Tails Self-Similarity Simulations 0.01

0.001 Single Req. One Click P2P Flow 0.0001 H2H Flow Client Sess. Complementary Distribution Function 1e-005 10 100 1k 10k 100k 1M 10M 100M 1G 10G Size in Bytes

P2P Port to Port H2H Host to Host Data: ADSL Münster Timeout 10min © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-19

Flow Durations replace logo s l Webb sseessssiioonns 1100%% ooff aalll We r thann 33hhrrss Chapter 6 1 aarree lloonnggeer tha Introduction Web Statistics ctionnss TCP Effects 0.1 of aallll ccoonnnneectio OOnnllyy 4400%% of Heavy Tails r thann 1100 sseecc aarree lloonnggeer tha Self-Similarity Simulations 0.01

ws”” ffoorr nneeaarrllyy ““PPoowweerr LLaaws 0.001 of mmaaggnniittuuddee ffoouurr oorrddeerrss of

Single Req. 0.0001 One Click HTTP Conn.

Complementary Distribution Function H2H Flow Client Act. 1e-005 0.1m 1m 10m 100m 1 10 100 1h 1d Duration in s xppeeccttaattiioonn α ⇒ iinnffiinniitteeeex P2P Port to Port α<<11 ⇒ unttiill ∞∞ iff ccoonnttiinnuueedd un H2H Host to Host Measurement: ADSL Münster i Timeout 10min © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-20 Chapter 6: replace logo Statistics and Performance

6.3 Long-Range Dependence and Self-Similarity replace logo

Chapter 6 Relative variance does not decrease as fast as expected Introduction on time scale aggregation Web Statistics still usual reduction on ensemble aggregation (multiple sources) Self-Similarity Simulations “fractal” or “self-similar” characteristics mean bit rates over time mean packet rates over time due to heavy-tailed distributions of ON phases causing long-range dependence

Large File Size Long-Range Self- Variance Dependence Similarity

Limits packet level time resolution instationarity -> check time dependence of traffic parameters

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 6 Edition Summer 2004 6-22 Measured SMTP Traffic Poisson Traffic replace logo 10s Aggregates over 10000s

1s Aggregates over 1500s

0.1s Aggregates over 150s

10ms Aggregates over 15s

Self-Similarity replace logo Different Views

Chapter 6 Dependence of variance on aggregation time Introduction Hurst Parameter H Web Statistics 1 mt Self-Similarity Y m = X VAR(Y (m) ) ~ m−2(1−H ) Simulations t ∑ s t m s=m(t−1)+1

Long-Range Dependence autocorrelation function decays with k2(H-1) Hyperbolic instead of exponential decay of autocorrelation ρ = 2(H −1) → ∞ (k) Cov(X t , X t+k ) ~ k k

Spectral Density pole at zero σ2 ∞ f (λ) = ρ(k)eikλ ~ λ1−2H λ → 0 ; λ ∈[−π,π] π ∑ 2 k =−∞

Chapter 6 Mean Bit Rate in Aggregation Time Intervals m Introduction 1000 Web Statistics Short-Range HTTP CL HTTP H2H Self-Similarity Dependence FTP CL Simulations POP3 CL --((11--HH)) rtionnaall ttoo mm 100 pprrooppoortio

e m Coefficient of Variation llaarrgge m tionaarriittyy →→ lliimmiittsos off ssttaation 1 0.01 0.1 1 10 100 1000 10000 Aggregation Time in Seconds

Self-Similarity replace logo Estimating the Hurst Parameter

Chapter 6 Introduction Variance-Time Analysis Web Statistics plot variance of aggregate versus aggregation time Self-Similarity simple, easy to understand Simulations also gives second (variance) parameter slightly unreliable R/S Analysis classical approach for unknown mean and variance plot rescaled adjusted range versus interval length Periodogram Analysis shows increase of spectral density around zero Abry-Veitch Estimator using wavelet theory independent of stationarity determines H and variance parameter from regression of Wavelet coefficients

6.4 Issues with Simulations replace logo Steady State and Confidence

Chapter 6 Effects of long-range dependent traffic Introduction Web Statistics Self-Similarity steady state reached slowly Simulations stochastic generators (input processes!) observed system state (e.g. queue length)

High variability at steady state high probability of “swamping” sample

Standard deviation of batch means decreases slowly To reduce batch means standard deviation by a factor of 10: simulate factor of 101/(1-H) longer H=0.5: factor 100 longer H=0.9: factor 10 000 000 000 longer!

Chapter 6 ... can never be simulated ☺ Introduction Web Statistics M/G/1 has infinite expected waiting time if the “G“ has infinite variance 2 Self-Similarity ρ(1+ c ) Mean Waiting Time E[W ] = E[S] S Simulations 2(1− ρ) 2 + ry too cx 1 DDoonn‘‘tt ttry t Residual Lifetime E[R] = E[X ] latee iinnffiinniittyy!! 2 ssiimmuulat

model carefully consider packets instead of bursts or for TCP, use M/G/r-PS or M/D/1-PS instead of M/G/1 ce limit distributions inffiinniittee vvaarriiaannce valss in nfiiddeennccee iinntteerrval check validity of assumption ⇒⇒ iinnffiinniittee ccoonf (e.g. do simulation results change with limit?) introduce corresponding mechanisms into networks (e.g. limit on e-mail sizes)

Input Parameters replace logo

Chapter 6 Do not use the Normal distribution Introduction Finite probability for X<0 Web Statistics Self-Similarity Use input parameters that have a meaning Simulations and make sure the corresponding random variables have finite mean

TCP traces are generally invalid if simulation includes TCP model -> use file sizes if simulation does not include TCP -> only binary result possible YES: the simulated network does not disturb TCP NO: the simulated network disturbs TCP and results will be fundamentally different

The “mean packet size” is generally uninteresting Packet sizes have multimodal distributions

Chapter 6 Introduction Be careful not to simulate trivial scenarios ad infinitum Web Statistics Self-Similarity Ensemble statistics vs. single source statistics Simulations

Applications: Voice over IP on packet level other constant rate sources

Solutions in simple models: identify period and change phase cyclically use phase changing generators use frequency shifted generators

Questions replace logo

Chapter 6 6.1 How can you guarantee a limited queueing delay in a router? Introduction At what cost? Web Statistics 6.2 Find out the expectation and variance of the distributions Self-Similarity given on slide 6-9 Simulations 6.3 Assume you did a simulation of traffic with Hurst parameter Questions H=0.8 that took 10 seconds. How long does a simulation with confidence intervals reduced to one tenth take?

Information and Communication Networks

IP Based Networks and Applications Chapter 7: Quality of Service

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Chapter 7 7.1 What is Quality of Service? What is QoS? Best Effort Service 7.2 Best Effort Service DiffServ IntServ 7.3 Differentiated Services MPLS 7.4 Integrated Services SLAs 7.5 MPLS 7.6 Service Level Agreements

What is Quality of Service? replace logo General View

quality as perceived by users depends on Chapter 7 data manipulation (coding) What is QoS? network performance Best Effort Service end-system performance DiffServ protocol characteristics IntServ MPLS ITU distinguishes 3 aspects Quality of Service (QoS) SLAs souunndd performance of a communication network hhooww ggoooodd isis so alityy?? from the point of view of the user of a service oorr vviiddeeoo qquualit Grade of Service (GoS) the part of QoS that depends on y o yoouu ggeett aa bbuussy network dimensioning hhooww oofftetenn ddo y e neetwtwoorrkk?? (for TDM networks) ttoonnee ffrroomm tthhe n Network Performance the ability of a network to o youu ggeett?? h baannddwwiiddthth ddo yo deliver a requested or hhooww mmuucch b droppppeedd?? ny ppaacckkeettss aarree dro agreed service hhooww mmaany IETF community does not distinguish everything is called “QoS”

Chapter 7 ingress What is QoS? links Best Effort Service egress no problem if there is always DiffServ Router link less traffic than can be . . . IntServ forwarded on the egress link MPLS SLAs Router buffer can moderate effects of short-term overload in the milliseconds range . . . packets delayed by some time

longer-term overload leads to congestion effects packets delayed by a long time packets dropped due to finite buffer space

QoS Metrics replace logo Packet Level Metrics

Chapter 7 bit error rate What is QoS? Best Effort Service DiffServ packet loss probability IntServ correlated loss MPLS multiple loss SLAs availability of packet transport service two-way IP connectivity to destination

probability of out-of-order delivery duplication probability

delay delay variation

Chapter 7 Availability What is QoS? reliability (Can I reach the server?) Best Effort Service blocking probability (Am I allowed to use the service now?) DiffServ in-service failures (Does the service break down after I got IntServ started?) MPLS achievable bit rate SLAs reaction time to user input e.g. telephony connection set-up or Web page retrieval can consist of many packet transfer times + repetitions in case of losses audio / video quality achievable quality for a certain codec (time and space resolution, noise) impact of packet level effects on quality lost packets delayed packets (often equivalent to loss but impact on synchronization)

Admission Control replace logo

Aim: Chapter 7 Once a user has been admitted to a service, they should have What is QoS? a chance to finish their task. Best Effort Service DiffServ Avoid: interruption of audio/video communications IntServ interruption of long file transfers MPLS (repeated transfer wastes resources) SLAs Mechanism: Admit only the amount of traffic a network can handle. Block the rest of the traffic. Problems: blocking also reduces perceived quality → AC does not help on insufficiently dimensioned networks resource requirements are hard to describe (e.g. for elastic traffic) all concerned network links need to take part in the admission decision processing and communication overhead complexity of network nodes © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-8 7.2 Best Effort Service replace logo Problems

Chapter 7 In the current Internet (and most IP networks) all traffic flows What is QoS? suffer under overload Best Effort Service no protection of “old” connections DiffServ no protection against overload where individual throughput IntServ drops to zero MPLS time-out of connections, very large retransmission timer values repetition of file transfers wastes bandwidth SLAs

traffic bursts cause delay variation problem for “real-time” services late packets are equivalent to lost packets for audio and video

Throughput per Connection Number of TCP Connections le ...buutt iitt iiss ssiimmpple an rreeaacchh aa ...b ...... aanndd yyoouu ccan orkk uuttililiizzaattiioonn rks hhigighh nneetwtwor ...... aanndd iitt wwoorks © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-9

Overdimensioning replace logo

Chapter 7 Simple approach to deal with the QoS problem What is QoS? “throw bandwidth at the problem” Best Effort Service DiffServ Keep network utilization below 10% high cost per bandwidth! IntServ engineers don’t like wasted resources MPLS SLAs Capacity upgrade planning required traffic tends to grow and increase utilization

No protection against sudden changes of traffic profiles e.g. sudden focus of interest on one Web site No protection against delay variation due to short-term traffic bursts e prriioorriittiieess?? t yoouu iinnttrroodduucce p ssoo wwhhyy ddoonn‘‘t y

Chapter 7 Differentiated Services (DS) described in RFCs 2474 What is QoS? and 2475 Best Effort Service Forwarding Classes DiffServ per-packet action in routers IntServ class encoded in IP packet header (using the IPv4 TOS field) MPLS resources are allocated to aggregated traffic, not individual SLAs flows traffic policing at the edge (conditioned, e.g. shaped, traffic accepted) class-based forwarding in the core Assured Forwarding (AF) certain rate is allowed Expedited Forwarding (EF) priority service to offer low delay or low loss, shaped bit rate default (Best Effort, BE)

Class of Service AF Assured Forwarding BE Best Effort instead of service guarantees DS Differentiated Services “forwarding behavior” EF Expedited Forwarding PHB Per Hop Behavior (Per Hop Behavior, PHB) TOS Type of Service © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-11

Differentiated Services (2) replace logo

Chapter 7 desired PHB specified in DS (TOS) field What is QoS? DS code points (DSCP) defined locally or by standards Best Effort Service organization routers read DS field to decide which queue to put a packet in DiffServ IntServ setting the DS field MPLS packet classifier (boundary node at network edge) sets DS SLAs values (“marking”) check packet origin (+destination, protocol etc) long-term contract between user and ISP (SLA) allows user (IP address, MAC address) to use premium service DSCPs Conditioning / usage control meter observes usage H BN Conditioning Actions H BN Network BN Boundary Node remarking DS Differentiated Services shaping BN DSCP DS Code Point H Host or Customer Network dropping ISP Internet Service Provider Network PHB Per Hop Behavior SLA Service Level Agreement TOS Type of Service © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-12 7.4 Integrated Services replace logo

Chapter 7 Explicitly set up a connection before sending traffic What is QoS? resource reservation in network nodes along the path Best Effort Service ensure that there is enough bandwidth DiffServ block set-up request if traffic cannot be carried IntServ or if specified delay/loss targets could not be met MPLS IntServ framework wants to guarantee upper delay bounds SLAs s) undss ((qquuaannttiillees) staattisisttiiccaall bboound st ficieenntt change of all IP routers required aarree mmoorree eefffici participation in resource reservation signalling local resource reservation per-flow queueing abell iinn IIPPvv44!! ere iiss nnoo flflooww llabe routers need to combine TThhere address, port and protocol numbers to identify flows

applications need to know traffic specification e.g. for leaky bucket or Generic Cell Rate Algorithm policer / shaper

Integrated Services replace logo RSVP

Resource reservation protocol (RSVP) described in Chapter 7 RFC2205 What is QoS? IP protocol ID 46 (raw IP packets), optional transmission on Best Effort Service UDP DiffServ router alert option [RFC 2113] set IntServ PATH message from origin to destination MPLS each router stores a “path state” per flow, SLAs including the previous hop RESV message from dest. to origin uses recorded previous hop H1 R R to follow the path back H2

PATH R R R Soft State principle RESV periodic repetition of PATH and RESV messages HHost unidirectional operation ID Identifier R Router compliant with existing IP routing RSVP Resource reverse data can take another path in the network Reservation Protocol separate signalling required for reverse data path © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-14 Integrated Services replace logo COPS

Chapter 7 What is QoS? Common Open Policy Services (COPS) Best Effort Service DiffServ IntServ Policy Decision Points (PDP) in the network MPLS required for globally (at least network-wide) coordinated policies SLAs know who is allowed to do what each router can ask a PDP if the global policy allows a specific client request to be granted

COPS data format is compatible to RSVP simplifys routers’ actions Problem: Protocol is well specified data structure semantics are not

7.5 MPLS replace logo

Chapter 7 Multi Protocol Label Switching What is QoS? originally designed to simplify IP forwarding Best Effort Service Idea: hheerree ccoommeess DiffServ abell attach (prepend) a label to each IP datagram tthhee ffllooww llabe IntServ routers can store specific handling instructions for each flow MPLS next hop / traffic class / mapping onto Link Layer pipes SLAs Label Switching multiple “label switched paths” (LSP) per link like ATM: translation table from incoming to outgoing LSP instead of flow identification plus next-hop lookup per packet Forwarding Equivalence Class (FEC) general concept for “what the forwarding decision is based on” e.g. destination IP prefix / egress router / application flow Advantage over pure switching label switching can be limited to a part of the traffic ATM Asynchronous Transfer Mode FEC Forwarding Equivalence Class LSP Label Switched Path MPLS Multiprotocol Label Switching © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-16 MPLS replace logo Label Distribution

Chapter 7 Label Switched Paths need to be managed What is QoS? Best Effort Service DiffServ Label distribution protocols IntServ RSVP-TE extension of RSVP MPLS label distribution, explicit routing, bandwidth reservation for LSP SLAs rerouting of LSP after failure, etc LDP specially designed label distribution protocol hard state label switched router discovery CR-LDP constraint-based route LDP explicit routing, resource reservation, route pinning

LDP Label Distribution Protocol LSP Label Switched Path RSVP Resource Reservation Protocol TE Traffic Engineering © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-17

MPLS replace logo Traffic Engineering

Chapter 7 LSPs can have allocated bandwidth What is QoS? flexible way to optimize or reroute traffic flows in a network Best Effort Service DiffServ Label switching can overcome standard IP routing limitations classical IP routing cannot fully distribute traffic IntServ RSVP allows full optimization of routing for a given traffic matrix MPLS on a network topology SLAs

R2 N1

R1 R4 N3

N2 R3 nd NN fromm NN1 aand 22 allyy,, aallll ttrraaffffiicc fro 1 me ccllaassssiiccall to taakkee tthhee ssaame woouulldd hhaavvee to t ttoo NN33 w nd RR eenn RR1 aand 44 rroouuttee bbeettwwee 1

Different routes can be allocated for different QoS classes

IP shortest path routing is determined by Chapter 7 link / interface cost metrics What is QoS? Best Effort Service by changing those metrics, routing can be changed DiffServ link loads can be reduced by appropriate routing IntServ 11 MPLS Example (simplified): R3 R4 R5 N3 SLAs

1 1 hop count based 1 N R R N routing metrics 1 1 2 2 flows from N1 to N2 and N1 to N3 all go via the link R1-R2

11 R3 R4 R5 N3

1 3 1 N1 R1 R2 N2 changed metrics flows from N1 to N2 and N1 to N3 take different paths

Traffic Engineering without MPLS replace logo Optimization of Routing Metrics

Chapter 7 link loads can be reduced by appropriate routing What is QoS? Best Effort Service highly non-linear influence of metrics on link loads DiffServ hard to find out metrics for optimum load distribution IntServ not every target routing can be realized with metrics MPLS linear solution mechanisms not applicable SLAs metrics can be optimized using heuristic approaches greedy search always increase metric value of the link with highest load genetic algorithms vector contains all link cost metrics of the network population of several such vectors is a generation subsequent generation created through copy, crossover, mutation controlled by “fitness” indicated by e.g. highest link load simulated annealing random movement in 2n-dimensional discrete parameter space (for a network with n links)

© Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-20 Traffic Engineering without MPLS replace logo Optimization in the “COST 239” Example Network

hop count based routing optimized routing metrics mean link load = 24.38% mean link load = 24.69% max. link load = 71.35% max. link load = 38.75%

ECMP (Equal Cost Multi-Path) option enabled in both cases © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 7 Edition Summer 2004 7-21

7.6 Service Level Agreements replace logo

Chapter 7 Service Level Agreement (SLA) What is QoS? contract between ISPs or Best Effort Service contract between ISP and end user / company DiffServ IntServ Service Level Agreement (SLA) consists of MPLS Service Level Specifications (SLS) SLAs prices and measures to be taken if SLS are violated

Examples for SLS SLS1: packet delay bound between nodes A and B in the network 3 samples every 5 minutes 90% of samples are less than 50ms SLS2:

destination network NB is unreachable for at most 5 minutes per month 10 consecutive packets (one every second) do not reach the destination

Chapter 7 What is QoS? Example for measures Best Effort Service get 10GB free data transmission DiffServ if SLS1 or SLS2 is violated in at least 3 consecutive months IntServ MPLS Control of SLAs SLAs offer monitoring services for SLS related quantities to users (via Web) active or passive measurement by users latedd SSLLSS aarree bannddwwiiddtthh rreelate or ba sibllee)) ttoo mmoonniittor Different objectives! hhaarrdd ((iimmppoosssib wide area ISP wants to have high network utilization offers SLA within its network end user wants to have end-to-end performance multiple ISPs involved

Questions replace logo

Chapter 7 7.1 Find out the availability of your favourite Web server. How often What is QoS? (out of 50 experiments) do you get the entry page within Best Effort Service reasonable time? How often do you get no answer at all? DiffServ 7.2 Have a look at some major ISPs’ Web sites and check the SLAs IntServ they offer their customers. MPLS 7.3 Can different QoS classes be introduced with “flat rate” pricing? SLAs

Questions 7.4 What is the difference between in-band and out-of-band network management? What are the advantages / disadvantages? 7.5 What is the difference between authentification and authorization? 7.6 Are there other ways than encryption to achieve confidential communication? 7.7 What is the format of an IPv6 packet header? What fields have been added / left out / moved to options compared to an IPv4 header?

Information and Communication Networks

IP Based Networks and Applications Chapter 8: Network Management

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Chapter 8 8.1 Introduction Introduction Configuration Mgt. 8.2 Configuration Management Performance Mgt. 8.3 Performance Management Fault Mgt. SNMP MIBs 8.4 Fault Management SNMP Protocol 8.5 SNMP MIBs 8.6 SNMP Protocol

8.1 Network Management replace logo Introduction

Chapter 8 Introduction Idea Configuration Mgt. manage all relevant network elements from a small number of Performance Mgt. management centers Fault Mgt. keep the network running SNMP MIBs detect (and possibly repair) faults SNMP Protocol detect possible problems before faults (especially on PHY layer) ensure that contractual requirements are met keep up with necessary configuration changes new users, new connections to other networks, new tariffs

Management Tasks Configuration Management Performance Management Fault Management Accounting Management Security Management

Chapter 8 Introduction “Simple” Network Management Protocol (SNMP) Configuration Mgt. specification of data structures (MIB Management Information Performance Mgt. Base) Fault Mgt. specification of transfer encoding SNMP MIBs specification of a communication protocol SNMP Protocol n mooddeell”” ““iinnffoorrmmaattiioon m

In-band network management uses the IP network for communication can be introduced with little effort no special management network required no separate technology required depends on working IP network management impossible if network elements are unreachable ectss oorr rroouuttiinngg pphhyyssiiccaall ddeeffect t maannaaggeemmeenntt eerrrroorrss aaffffeecct m

Management Architecture replace logo

Chapter 8 Architecture Introduction management station(s) Configuration Mgt. network elements running management “agent” software NE Performance Mgt. NE routers Fault Mgt. servers NE SNMP MIBs printer, terminal, NE SNMP Protocol Web, remote access, . . . NE NE

NE NE MS other Network

Basic Mechanisms request information from an agent set configuration data (center to agent) notify center of new information (“trap”: agent to center)

Chapter 8 Objective: Introduction be able to automatically generate current network graph Configuration Mgt. detect configuration rather than have operators document it Performance Mgt. necessary for detecting mismatches Fault Mgt. between target and actual configurations SNMP MIBs topology discovery SNMP Protocol connectivity discovery discovery of element configuration routing tables protocol and port parameters configuration tracking service collection of “history” data to allow going back to the last working set-up backup of configuration information automatic distribution of changes new policies, routing tables, software versions, ...

Configuration Management (2) replace logo

Chapter 8 Introduction ... is easy in static configurations Configuration Mgt. Performance Mgt. ... has problems in dynamic (chaotic) environments Fault Mgt. as found in many small to medium size enterprise networks SNMP MIBs SNMP Protocol ... should help tracking down errors errors can be introduced by configuration changes have the current configuration available when locating other errors

Configuration tracking needs to be done continuously archive results dy ooccccuurreedd,, erroorr hhaass aallrreeaady verryy!! WWhheenn aann err igurraattiioonn ddiissccoove o laattee ffoorr ccoonnffigu iitt mmaayy bbee ttooo l

Chapter 8 Introduction Objective: Configuration Mgt. Prevent load or configuration related performance problems Performance Mgt. Performance problems may be perceived as “failures” by users! Fault Mgt. “hard” problems (equipment failure) may manifest themselves SNMP MIBs as performance problems due to automatic reconfiguration SNMP Protocol

Approach: Monitoring of network performance periodic evaluation of results network-wide observations automatic baselining

Also useful for end-user interface network manager knows problems before phone calls come in users can get (good) performance statistics from Internet/Intranet server

Performance Management replace logo Examples

Chapter 8 Examples for performance / problem measures Introduction link utilization Configuration Mgt. CPU load in routers Performance Mgt. packet loss rates Fault Mgt. packet delay SNMP MIBs link failures SNMP Protocol

Long-Term misconfiguration link bandwidth traffic growth upgrade delay delay delay loss loss loss

Chapter 8 Introduction Error Detection Configuration Mgt. detect that an error has occured Performance Mgt. Fault Mgt. SNMP MIBs Fault Isolation SNMP Protocol find the error that caused the symptoms

Service Restoration take actions remote reconfiguration repair/exchange hardware request restoration of service from underlying service provider / carrier

Event Correlation replace logo

Chapter 8 Introduction Problem: deduce the true failure cause from (indirect) Configuration Mgt. indications Performance Mgt. indications are observed (e.g.: highly variable delay) Fault Mgt. SNMP MIBs SNMP Protocol condensation of raw data into information each single data item has little information combinatorial or temporal correlation of data

prevent event storms single fault can cause many measures to trigger alarms de-duplication of multiple events by network management software Do not overload human operators by too much (identical) information!

Chapter 8 Introduction routing instability has significant impact on network Configuration Mgt. performance Performance Mgt. metrics for route stability Fault Mgt. availability (time) SNMP MIBs mean time between failure or fail-over SNMP Protocol time to repair failure duration frequency of routing table updates

inter-domain route instability detection from BGP routing table events (route failure, repair, ...) intra-domain route instability detection failure logs certain routing protocol messages

8.5 SNMP MIBs replace logo

see RFC 1213, RFC 1907 and many others Chapter 8 Introduction Hierarchical structure of information Configuration Mgt. unique identification of information fields (for all vendors and Performance Mgt. nations) Fault Mgt. SNMP MIBs standard SNMP MIBs defined for many network element SNMP Protocol types allow retrieving information without knowledge of machine details get-next mechanism for retrieving “all information” without prior knowledge of what will be available readd tthhee WWhhoo wwoouulldd rea anyywwaayy?? element values encoded in ASN.1 hhaannddbbooookk an Abstract Syntax Notation defines content transfer encoding receiver can detect data type and encoding

ASN.1 Abstract Syntax Notation #1 MIB Management Information Base No object oriented structure SNMP Simple Network Management Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 8 Edition Summer 2004 8-14 SNMP MIBs replace logo Structure

Chapter 8 un- named Introduction Configuration Mgt. 1.3.6 Performance Mgt. joint- iso itu Fault Mgt. iso-itu inter- 1 2 net SNMP MIBs 3 1 SNMP Protocol org experi- directory mgmt private 3 mental 1 2 4 3

dod 6 mib 1

inter- addr. system ip icmp tcp udp faces trans. 1 5 6 7 2 3 4

SNMP MIBs replace logo Variables

Chapter 8 Introduction Numeric representations defined in standards (or privately Configuration Mgt. allocated) Performance Mgt. numeric representation Fault Mgt. e.g. 1.3.6.1.2.1.4.20 SNMP MIBs MIB variable name SNMP Protocol e.g. iso.org.dod.internet.mgmt.mib.ip.ipAddrTable hierarchically substructured e.g. consisting of ipAdEntAddr, ipAdEntIfIndex, ipAdEntNetMask, ipAdEntBcastAddr, ipAdEntReasmMaxSize

Chapter 8 Introduction Abstract Syntax Notation 1 (ASN.1) Configuration Mgt. Performance Mgt. used to describe entries Fault Mgt. e.g. SNMP MIBs ipAddrEntry ::= SEQUENCE { SNMP Protocol ipAdEntAddr IpAddress, ipAdEntIfIndex INTEGER, ipAdEntNetMask IpAddress, ipAdEntBcastAddr IpAddress, ipAdEntReasmMaxSize INTEGER (0..65535) } also specifies binary transfer encoding similar to TLV (Type, Length, Value) principle Type specifies a data type length gives total length of field SEQUENCE type allows hierarchical specification

8.6 SNMP Protocol replace logo

“Simple” Network Management Protocol Chapter 8 [RFCs 2570, 2575, 2572] Introduction uses UDP (port 161; port 162 for traps) Configuration Mgt. Performance Mgt. SNMP Version 3 features Fault Mgt. message authentication (who sent the message?) privacy (avoid unauthorized reading) lemss SNMP MIBs MMaajjoorr pprorobblem authorization and view-based access control 2! SNMP Protocol ooff SSNNMMPPvv2! (who can change what?) remote configuration of security system Management Station Communication beween Network Management Element Management Application and Application Network Element SNMP read configuration SNMP Agent read counters / statistics Engine modify configuration IP Network notify management station of event configure security

Chapter 8 GetRequest Introduction get the value of a list of specified variable(s) Configuration Mgt. Performance Mgt. GetNextRequest Fault Mgt. get the value and ID of the variable following the given one SNMP MIBs allows to browse unknown MIBs SNMP Protocol GetBulkRequest (SNMPv3) Response send the requested value back SetRequest change the value of a variable (e.g. for configuration changes) InformRequest (SNMPv3) SNMPv2Trap unsolicited mesage, see next slide Report (SNMPv3)

SNMP Traps replace logo

Chapter 8 Introduction Traps Configuration Mgt. used for spontaneous communication from agent to server Performance Mgt. server address is pre-configured in agent Fault Mgt. server is prepared to receive Trap messages from (many) SNMP MIBs agents SNMP Protocol

Trap Types coldStart warmStart linkDown linkUp authenticationFailure egpNeighborLoss enterpriseSpecific

Chapter 8 Messages consist completely of ASN.1 transfer encoded Introduction fields Configuration Mgt. message formats specified in ASN.1 Performance Mgt. Fault Mgt. SNMPv3Message SNMP MIBs message version SNMP Protocol header data message ID maximum reply size flags and security model security parameters scoped PDU data scoped PDU context engine ID and name PDU 0 (GetRequest) exaammppllee:: ex U request ID GeettReReqquueesstt PDPDU error status and error index G list of object identifiers encrypted PDU (octet string)

Questions replace logo

Chapter 8 8.1 Compared to SMTP and HTTP, do you really consider SMTP Introduction a “simple” protocol? What is simple about it? What is not? Configuration Mgt. 8.2 What is the default community string for reading an SNMP Performance Mgt. variable? Fault Mgt. SNMP MIBs 8.3 Find the “snmpget” public domain SNMP client, start snmpd SNMP Protocol (e.g. on a Linux machine) and request some values. 8.4 Do you have to read the MIB specifications to understand the Questions data returned by the “snmpwalk” tool?

Information and Communication Networks

IP Based Networks and Applications Chapter 9: Security

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Chapter 9 9.1 Introduction Introduction Improving Security 9.2 Methods for Improving Security Frameworks 9.2.1 Methods for Confidentiality and Integrity Firewalls 9.2.2 Methods for System Security Absolute Security? 9.3 Internet Security Frameworks 9.3.1 Authentication Frameworks 9.3.2 Network Layer Security: IPSec 9.3.3 Transport Layer Security: SSL and TLS 9.3.4 Application Layer Security: PGP 9.4 Firewalls 9.5 Absolute Security?

9.1 Introduction: Areas of replace logo Security Problems in Communication Networks

Chapter 9 Security of Communications Introduction data transport Improving Security e.g. risk of eavesdropping Frameworks Security of End Systems Firewalls data storage and manipulation Absolute Security? e.g. risk of unauthorized use risk introduced/increased A by network connectivity B Communication Network PePeooppllee hhaavvee us ddiiffffeerreenntt ffooccus M Security of the Communication Network data transport e.g. risk of unauthorized use

Confidentiality Chapter 9 no “eavesdropping” tion Introduction →→ EnEnccrryypption no unauthorized access to information Improving Security Frameworks Firewalls turree →→ ddiiggiittaall ssiiggnnaatu Absolute Security? Data Integrity no unauthorized manipulation of information recipient receives data identical to what the originator sent Data authenticity originator cannot claim fake identity Guaranteed delivery of messages intruder cannot remove messages completely le oluttiioonn aavvaaiillaabble nnoo ssiimmppllee ssolu s chhaannnneell commmuunniiccaattiioonns c →→ uussee ootthheerr com erss sequueennccee nnuummbber →→ uussee pprriivvaattee seq

all of the above: with or without detection by originator or recipient

Security of End Systems replace logo

Chapter 9 Access to confidential data Introduction e.g. leaking of credit card account information Improving Security Frameworks Firewalls Manipulation of data Absolute Security? change or delete information

Change of system manipulation of configuration e.g. authorization or account information unauthorized running of programs import of foreign (malicious) programs

Denial of Service (DoS) attacks cause system overload cause system to hang or crash

Chapter 9 Unauthorized network usage Introduction use network without paying Improving Security Frameworks Firewalls Modification of network configuration Absolute Security? change of DNS entries change of routing information

Denial of Service (DoS) attacks like “end system” attacks, directed to network elements DNS servers, routers, network management stations impact availability of network service access service packet delivery to selected destinations FCss:: ulaattiioonn ffrroomm RRFC TTyyppiiccaall ffoorrmmul suess aarree nnoott ““SSeeccuurriittyy iisssue thiiss mmeemmoo..”” ddiissccuusssseedd iinn th

“10 most crucial Internet Security Threats” replace logo

Chapter 9 1. BIND weaknesses Introduction 2. Vulnerable CGI programs and application extensions on Improving Security Web servers Frameworks 3. RPC weaknesses Firewalls 4. Remote Data Services in Microsoft Internet Information Absolute Security? Server 5. Sendmail and MIME buffer overflows 6. Solaris system administration and mount daemons 7. improper configuration of file sharing (Windows, Unix, Apple) 8. weak (or no) passwords for user or root accounts 9. IMAP and POP buffer overflows or incorrect configuration 10. default SNMP community strings (“public” and “private”) Neettwwoorrkk d SSyysstteemmss aanndd N FoFoccuuss oonn EnEnd Source: www.sans.org, 2001 © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 9 Edition Summer 2004 9-8 Attacks replace logo

Chapter 9 Eavesdropping Introduction data Improving Security user identity traffic flows Frameworks Firewalls Denial of Service Absolute Security? Spoofing gain network access by taking on a trusted machine’s address Physical compromise access to hard disk access to computer in “stand-alone” state access to communication line some switches and most operating systems allow capturing packet contents and copying to remote destinations Replay attack record communication and replay at a later time time stamps can limit reusable time Trojan horses / virus programs

9.2 Methods for Improving Security replace logo

Chapter 9 Data manipulation methods Introduction encryption Improving Security Confidentiality digital signatures and Integrity signature checking on configuration files and programs System Security packet filtering, protocol filtering Frameworks Firewalls Absolute Security? Physical methods physical access control backup strategy separation of networks, hosts without network connectivity

Logistic methods res aa seccuurriittyy rreeqquuiires auditing and log evaluation GGoooodd se cesss el sseeccuurriittyy pprrooces double passwords mmuullttii--lleevvel selection of operating personnel

Chapter 9 Introduction Authentication Improving Security use encrypted communication for authentication also Confidentiality and Integrity System Security Encryption Frameworks symmetric key Firewalls asymmetric key Absolute Security? hybrid trust center

Digital Signature check integrity of data check identification of originator

Steganography

Encryption replace logo

Chapter 9 Introduction use keys to encrypt and decrypt a plain text message P Improving Security Confidentiality and Integrity System Security Symmetric key methods (“Private Key” methods) fast operation, suitable for mass data encryption Frameworks one key needed for any pair of communication partners Firewalls risk of key being revealed Absolute Security?

A B secret key secret key P P Encryption Global Decryption Engine Internet Engine

encrypted file

Asymmetric key methods (“Public Key” methods) Chapter 9 generate pairs of keys where one cannot (easily) Introduction be computed from the other Improving Security Confidentiality use public key and secret key and Integrity Trust Center gives access to all public keys System Security Frameworks Firewalls B’s public A key from B’s secret key B Absolute Security? Trust Center P P Encryption Global Decryption Engine Internet Engine

encrypted file

Hybrid method generate random key for symmetric encryption use public key method to transfer symmetric key following communication encrypted using symmetric key (more efficient)

Digital Signature replace logo Public Key Method

Chapter 9 Introduction A can generate a signature from P using A’s secret key Improving Security anyone can check the signature using A’s public key Confidentiality and Integrity System Security Frameworks Firewalls A’s A secret key A’s public key B Absolute Security? P P Encryption Global Decryption Engine Internet Engine

plaintext + signature check signature

for encryption + signature, sign with secret key (A) and encrypt with public key (B) only B can read the message

Chapter 9 Introduction Information hiding instead of encryption Improving Security Confidentiality and Integrity System Security hide texts e.g. in large inconspicious audio or video files Frameworks set the least significant bits of some pixels or audio samples Firewalls according to the information to be hidden Absolute Security? not as efficient as encryption

not as obvious as encryption hard to find in a data stream hard to track even where encryption is illegal

also used for digital signatures for copyright digital “watermark” seccrreett IIss tthheerree aannyy se in tthhiiss iimmaaggee?? iinnffoorrmmaattiioonn in

9.2.2 Methods for System Security replace logo

Chapter 9 Protect systems by firewalls (see Section 9.4) Introduction Improving Security Intrusion Detection Confidentiality logging, auditing plus checking of logs and Integrity System Security alarm generation and notification Frameworks automatic effect recognition, pattern recognition Firewalls Authentication Absolute Security? plus Authorization concept Restrict system administrator access ensure trackability of actions do not allow anonymous administrator access e.g. force use of tools like “su” or “sudo” Install security patches e.g. against buffer overflows State-of-the-Art System Scanning against worms, viruses, trojan horses

Chapter 9 Introduction Definition of key formats Improving Security Frameworks Selection of algorithms Authentication IPsec Definition of protocols SSL key exchange PGP key management Firewalls Absolute Security?

Different frameworks for Authentication security (login) Network Layer security Transport Layer security Application Layer security

9.3.1 Authentication Frameworks replace logo

Chapter 9 plain passwords can be intercepted Introduction encrypted passwords can also be intercepted → Improving Security use challenge / response methods and mutual authentification → include timestamps Frameworks Authentication IPsec kerberos [RFC1510] KDC SSL authentication mediated through 0 PGP 1 key distribution centre (KDC) 2 Firewalls C S 1. KDC sends to client Absolute Security? session key encrypted with client key session key + client ID encrypted with server key = ticket 2. user forwards ticket to server 3. user decrypts session key, server decrypts ticket (→client ID and session key) → communication can use session key other methods used in RADIUS (see Section 5.4) chap/pap authentification

alternative: code generation cards C Client KDC Key Distribution Centre e.g. securID SServer © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 9 Edition Summer 2004 9-18 9.3.2 Network Layer Security: IPsec replace logo

Chapter 9 latest version specified in RFCs 2401–2410 Introduction provides security for any transport layer data over IP Improving Security extension service for IPv4 (protocol #50) Frameworks IPv6: part of the standard Authentication App. Layer Prot. IPsec Functions SSL TCP or UDP key exchange / management (IKMP) PGP IPsec Firewalls symmetric encryption (IPSP) authentification lower layer Prot. Absolute Security? Encapsulated Security Payload (ESP) Header Transport Mode: encryption of IP packet payload user data encrypted, but addresses readable authenticated encrypted IPv4 ESP TCP TCP ESP ESP Header Header Header Data Trailer Auth Tunnel Mode: encryption and encapsulation of complete IP packet original addresses of ESP Encapsulated Security Payload IKMP Internet Key Management Protocol IP packet are concealed IPSP IP Security Protocol © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 9 Edition Summer 2004 9-19

Ipsec (2) replace logo

Chapter 9 Authentication Header (AH) Introduction to detect manipulation Improving Security “signature” of header and payload (hash function) Frameworks IPv4 AH TCP TCP AH Authentication Header Authentication Header Header Data IPsec SSL Internet Key Exchange (IKE) [RFC2409] PGP ISAKMP: Internet Security Association and Key Management Firewalls Protocol [RFC2408] Absolute Security? Authentication Key Management Security Associations “Oakley” for key exchange, using the Diffie-Hellman principle:

f(x) = ax (mod p) “one-way” function (logarithm is hard to compute) parameters a and p are known by all users user i has private key Xi Xi public key is Yi =a (mod p) Xi XiXj for communication between i and j use Zij =Zji = (Yj) =a mod p use Zij for encryption and decryption (symmetric key)

Chapter 9 Transparent layer between TCP and application Introduction Netscape: “Secure Socket Layer” Improving Security IETF: “Transport Layer Security” Frameworks Authentication negotiation of IPsec encryption algorithm (e.g. RC2, RC4, DES, Triple-DES, IDEA) SSL cryptographic hash function (e.g. SHA, MD5) PGP key exchange protocol (e.g. RSA, Diffie-Hellman) Firewalls signature method (e.g. RSA, DSA; only for authentication) Absolute Security? TCP based Applications (HTTP, FTP, SMTP, ...) Handshake Change Cipher Alert Application Data Protocol Spec Protocol Protocol Protocol SSL Record Protocol TCP IP atioonn:: mmaaiinn aapppplliiccati hhttttppss © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 9 Edition Summer 2004 9-21

9.3.4 Application Layer Security: PGP replace logo

Chapter 9 Encryption and signature for e-mails hybrid method: IMEE Introduction tanddaarrdd:: SS//MMIM symmetric session key nneewweerr sstan Improving Security transmitted by public key encryption Frameworks Authentication special problem: offline communication IPsec SSL public keys mostly from “Web of trust” PGP Web pages Firewalls “finger” information Absolute Security? business cards certify a key yourself or trust somebody to certify keys

B’s public A key from B’s secret key B A’s keyring P P Encryption Global Decryption Engine Internet Engine

encrypted message

Chapter 9 Secure a whole enterprise network Introduction Improving Security Common point of trust Frameworks reduces effort in securing many computers reduces risk of a misconfigured computer compromising others’ Firewalls security Absolute Security? only one system to verify and observe only few services need to go across

Global viceess Internet sseelleecctteedd sseerrvic ougghh (insecure) ccaann ppaassss tthhrrou

l FFiirreewwaalll Intranet (protected)

Firewall Functions replace logo

Chapter 9 Network Layer Access Control Introduction which hosts are allowed to communicate (inside + outside) Improving Security User Level Access Control Frameworks user authentification Firewalls Absolute Security? Access Control Management Application Level Access Control limit applications and their functionality to a basic necessary level Isolation of internal services implementation errors in servers are less critical Logging, auditing and alarming Hide internal network structure

hes rreegguullaarrllyy:: ApApppllyy ppaattcches e! Firewalls must resist attacks d maaiinntteennaanncce! Fiirreewwaallllss nneeeed m prefered targets F

Chapter 9 Introduction as simple as possible Improving Security easy to implement Frameworks easy to understand implementation Firewalls Absolute Security? as little functionality as possible (per module) as little trust as possible (between modules) no trust in unprotected modules no trust in any WAN user consider attacks from both sides only provide minimum services block the rest protect firewall configuration restrict configuration access audit changes

Network and Application Layer Functions replace logo

Chapter 9 Packet Filtering Introduction rules specify what to do with a packet Improving Security on the basis of IP addresses (local and remote) and / or port Frameworks numbers Firewalls block access to unwanted servers and services Absolute Security? locally compiled lists or lists from service providers actions: pass through / translate network address / translate port / drop

Application Gateway restriction to basic functionality of application level protocols proxy server for http, ftp relay service for smtp, nntp

Combination of both can increase security

Chapter 9 Introduction Improving Security Outside world (insecure) Frameworks Global Firewalls Internet Absolute Security? Router with packet filter

Intranet

Inside (protected)

Firewall Concepts replace logo Bastion Host

Chapter 9 Introduction Improving Security Outside world (insecure) Frameworks Global Firewalls Internet Absolute Security? Outside Router route packets only Nettwwoorrkk”” to and from Bastion Host ““SSttuubb Ne

Bastion Inside Host Router Intranet proxy server and relay host Inside (protected)

Chapter 9 Introduction Improving Security Global Access Router block packets Frameworks Internet + Packet Filter Firewalls Absolute Security?

Public Services Screening Router prevent offer e.g. Host + Packet Filter IP spoofing Web service to outside

e.g. for for external mail Mail Host Bastion FTP and Web communication Host access Intranet

9.5 Absolute Security? replace logo

Chapter 9 Introduction Most, if not all methods have a residual error probability Improving Security can be made arbitrarily small, but never zero Frameworks Simple Examples Firewalls chance of guessing a parity bit right is 0.5 Absolute Security? good chance of manipulating an original text to fit a given 10 bit digital signature “brute force” attacks are always possible attacks that use little or no knowledge of the security mechanisms simply rely on probability e.g. (parallel and distributed) cracking of encryption keys try every possible key until you can decrypt the message try every possible password until you find rityy iinn one that matches the encrypted text PPeerrffeecctt sseeccuurit ll moovvee oonnee aarreeaa wwiill m othheerr aarreeaa tthhrreeaattss ttoo aannot

Chapter 9 9.1 Can plain text based protocols ever provide confidentiality? Introduction Improving Security 9.2 Are protocols using binary information safer than text Frameworks based protocols? Firewalls 9.3 Can you use challenge/response methods for e-mail Absolute Security? communication? 9.4 What do you need to know about a target system in order Questions to exploit a buffer overflow?

Information and Communication Networks

IP Based Networks and Applications Chapter 10: IPv6

Dr.-Ing. Joachim Charzinski [email protected]

Outline replace logo

Chapter 10 10.1 Introduction Introduction Addressing 10.2 Addressing IP Packet Header 10.3 IP Packet Header Autoconfiguration Security Support 10.4 Automatic Configuration Changes to others 10.5 Security Support Migration Strategies 10.6 Changes to Other Protocols 10.7 Migration Strategies

10.1 Introduction replace logo

Chapter 10 IP version 6 is the designated successor of IPv4 Introduction (see Chapter 2) Addressing also known as IPnG (next Generation) IP Packet Header version 5 was assigned for the (experimental) Autoconfiguration Stream Protocol (ST) described in RFCs 1883, 2460, 2462–2464, 2373–2375, 2526 Security Support Changes to others Migration Strategies Motivation for IPv6 increased address space to allow maintaining end to end transparency Introduction of Quality of Service mechanisms on Network Layer Improvement of Network Layer Security (end to end) ccaann aallssoo bbee ithh IIPvPv44 completely new header format ddoonnee wwit larger addresses new options and option handling 32bit alignment for faster processing

Chapter 10 Reasons for introducing IPv6 Introduction address space problem solved Addressing especially interesting for mobile networks and large growth IP Packet Header countries (China) support of flow labels Autoconfiguration full support for tunnelling and interworking Security Support v6 over v4 networks Changes to others v4 over v6 network not defined yet (not yet needed) Migration Strategies Reasons for not introducing IPv6 changes required to all routers and end systems changes required to some applications IPv4 works well enormous overhead due to long addresses (especially for short packets) addressing problem not as urgent as believed 5 years ago label stacking not supported → flow label field not useful for MPLS

MPLS Multiprotocol Label Switching © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-5

10.2 Addressing replace logo

128 bit (16 octets) addresses [RFC1887] Chapter 10 more than 1024 addresses per m2 of earth surface Introduction enough freedom for structured addressing Addressing ed ffrroomm lleessssoonn lleeaarrnned Address Types s shhoorrttaaggee IP Packet Header IIPPvv44 aaddddrreesss s Autoconfiguration unicast addresses [RFC2374] global aggregatable / link local / site local Security Support anycast addresses Changes to others deliver packet to one of a set of addresses that has the shortest Migration Strategies path multicast addresses textual representation 8x16bit integers, represented by 4 hex digits e.g. 1080:0000:0000:0000:00AB:0801:200E:3AB2 short form: 1080:0:0:0:AB:0801:200E:3AB2 “::” used to denote as many “0” fields as necessary (once per string), e.g. 1080::AB:0801:200E:3AB2 prefix indication in decimal, e.g. 1090:2ADC:3300:: /40 for a 40 bit prefix © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-6 Division of IPv6 Address Space replace logo High-Level Address Types

Chapter 10 First bits Type of Address Introduction 0000 0000 reserved for IPv4 compatibility Addressing 0000 001 ISO NSAP Addresses IP Packet Header 0000 010 IPX Addresses Autoconfiguration 001 Aggregatable Global Unicast Security Support Changes to others 1111 1110 10 Link-Local Unicast Migration Strategies 1111 1110 11 Site-Local Unicast 1111 1111 Multicast unassigned: 0000 0001, 0000 011, 0000 1, 0001, 010, 011, 100, 101, 110, 1110, 1111 0, 1111 10, 1111 110, 1111 1110 0

IPv4 compatibility addresses IPv6 address 80 bits (all zero) 16 bits 32 bits also available: 0000...0000 0000...0000 IPv4 address yes 0000...0000 FFFF...FFFF IPv4 address no

Addressing replace logo Aggregatable Global Unicast Addresses

Chapter 10 Three-level hierarchy Introduction Number of bits in each field: Addressing 3 13 8 24 16 64 IP Packet Header P TLA ID res. NLA ID SLA ID Interface ID Autoconfiguration Security Support P (format prefix 001 for aggregatable global unicast addresses) Changes to others TLA ID: Top Level Aggregation Migration Strategies Transport Provider, e.g. an ISP with global network res.: reserved for future use (all zeroes) NLA ID: Next Level Aggregation (e.g. an ISP) SLA ID: Site Level Aggregation (e.g. like an IPv4 subnetwork) Interface Identifier e.g. random number (privacy extension [RFC3041] e.g. encoding of lower layer hardware address (with some bits in between) or EUI64 addresses ARP replaced by Neighbor Discovery for IPv6 ARP Address Resolution Protocol EUI End User Interface ICMP Internet Control Message Protocol ID Identifier ISP Internet Service Provider © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-8 10.3 IPv6 Packet Header replace logo Changes

Chapter 10 changes to the IPv4 header Introduction Addressing Version IHL Precedence / TOS Total Length IP Packet Header Identification Flags Fragment Offset Autoconfiguration Time to Live Protocol Header Checksum Security Support Changes to others Source Address Migration Strategies Destination Address Options Padding

User data ...

field still present field removed field replaced (new meaning) field moved into extension header

IPv6 Packet Header replace logo Changes (2)

Chapter 10 IPv4 fields removed from IPv6 headers Introduction Header length Addressing Identification IP Packet Header Header Checksum Autoconfiguration Security Support Changes to others IPv4 fields changed for IPv6 headers Migration Strategies Precedence and Type of Service → Traffic Class (DiffServ Code Point) Total length → Payload Length Time to live → Hop Limit Protocol → Next Header

Extension Headers e.g. for Fragmentation (replaces Flags & Fragment Offset fields) use “next header” field

Chapter 10 Concept optional Introduction Base Extension Extension Addressing . . . Header Header #1 Header #n User data ... IP Packet Header Autoconfiguration Security Support Base Header Format Changes to others Version Traffic Class Flow Label Migration Strategies Payload Length Next Header Hop Limit

Source Address

Destination Address

Extension Headers replace logo

Extension Header format Chapter 10 Introduction Next Header Header Length Addressing Option(s) IP Packet Header Autoconfiguration Security Support TLV (Type, Length, Value) encoding for options Changes to others Type Length Value ... Migration Strategies first 2 bits of Type determine handling of unknown options: 00=skip, 01=discard packet, 10=discard packet and send ICMP message, 11=like 10 but only if destination address was not multicast Header Sequence IPv6 Base Header (40 Octets) Authentication Header Hop-by-Hop options (variable) (variable) Destination options (variable) Encapsulation Security Routing Header (variable) Payload (variable) Fragment Header (8 Octets) Destination Options (variable)

Chapter 10 IPv6 Packet with TCP payload, no extension headers Introduction Addressing Base Header Next=TCP TCP segment IP Packet Header Autoconfiguration Security Support IPv6 Packet with routing header and TCP payload Changes to others Base Header Routing Header Migration Strategies Next=Routing Next=TCP TCP segment

IPv6 Packet with routing header and TCP payload Base Header Routing HeaderFrag. Header Next=Routing Next=Fragment Next=TCP Part of TCP segment

n entt ooff eexxtteennssiioon Uniiffiieedd ttrreeaattmmen tocoollss Un nexxtt llaayyeerr pprrootoc hheeaaddeerrss aanndd ne

Jumbo Payload Option replace logo

Chapter 10 “Jumbogram” Introduction Addressing IP Packet Header option field contains extra 4 Bytes length indicator Autoconfiguration maximum length of packet increased to 4GB Security Support Changes to others not to be used in conjunction with fragmentation Migration Strategies

Changes necessary to TCP and UDP [RFC2147] UDP length=0 indicates “use IPv6 length value” TCP MSS=65535 indicates infinite MSS TCP URG pointer can only address data up to octet 65535

especially interesting for high-speed reliable local networks reduce processor interrupt load at end systems MSS Maximum Segment Size URG Urgent © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-14 Fragmentation replace logo

Chapter 10 IPv6 routers do not fragment packets Introduction Path MTU discovery is mandatory Addressing if path MTU discovery is not possible, send packets for small IP Packet Header MTU size Autoconfiguration if absolutely necessary, fragment at source (“end-to-end Security Support fragmentation”) Changes to others re-discovery may be necessary after path change Migration Strategies

source and destination nodes can do fragmentation and reassembly to transmit larger size payloads fragment offset / identification principle similar to IPv4 use Fragment Header to indicate next header fragment offset “more fragments” (1 bit)

identification MTU Maximum Transmission Unit © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-15

QoS Support replace logo

Chapter 10 Introduction Traffic Class / DiffServ Code Point Addressing IP Packet Header not counted in check sum or authentification information Autoconfiguration routers can change the Traffic Class value without recomputing Security Support checksums Changes to others Migration Strategies Flow Label simplifies special treatment for flows flow identified by source IPv6 address and flow label random uniform choice of flow labels optimizes hashing in routers o accccoommooddaattee Tooo sshhoorrtt tto a exact function still to be defined To bel ssttaacckk!! aann MMPPLLSS llaabel

Chapter 10 Neighbor Discovery (ND) [RFCs 1970, 2461] Introduction find directly connected nodes Addressing using ICMPv6 packets for communication and lower layer IP Packet Header multicast Autoconfiguration Functions Security Support Router Discovery Changes to others Prefix Discovery Migration Strategies Parameter Discovery Stateless Autoconfiguration Address Resolution Next Hop Lookup Unreachability Test address duplicate detection Redirect Router Renumbering [RFC 2072] centrally change all address prefixes within a subnetwork e.g. for changing to a new ISP or campus address restructuring

10.5 Security Support replace logo

Chapter 10 Introduction Extension of IPSec [RFC2401] Addressing Security Association IP Packet Header defined by destination address and Security Parameter Index Autoconfiguration (SPI) Security Support Key for authentification / encryption Changes to others Algorithms for authentification / encryption Migration Strategies Key lifetime Security association lifetime Source address Security level (confidential, unclassified, etc)

Key Management Internet Key Exchange (IKE) [RFC2409] Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]

Chapter 10 Introduction Routing protocols Addressing need to handle new address format IP Packet Header Autoconfiguration Security Support DNS Changes to others new “A6” resource record for “A” type requests Migration Strategies DNS update message [RFC2136] for dynamic DNS

TCP and UDP Socket Interface (Addresses) UDP now requires checksum reduced maximum payload length

Plus any other protocol that handles IP address information e.g. FTP, H.323

ICMPv6 replace logo

Chapter 10 Introduction New functional structure compared to ICMPv4 Addressing IP Packet Header Autoconfiguration Error Reports Security Support Changes to others Migration Strategies Echo Request / Reply

Group Management replacement for IGMP group membership query, report, termination

Neighbor Discovery router solicitation / advertisement neighbor solicitation / advertisement redirect © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-20 10.7 Migration Strategies replace logo

Chapter 10 Described e.g. in RFCs 1933, 2767 Introduction IPv6 applications Addressing IP Packet Header v6 and v4 IP layers Autoconfiguration selection via v6 address Security Support observation of IPv4 mapped IPv6 address Changes to others → communicate via IPv4 Migration Strategies

Dual Protocol Stacks Tunnels IPv6 Application IPv6 IPv4 IPv6 Network Tunnel Network IPv6 Sockets Network TCP for IPv6 TCP for IPv4 IPv6 IPv4 Translators Subnetwork Layer IPv6 Trans- IPv4 Network lator Network

Migration Strategies replace logo Tunnelling of IPv6 over IPv4 networks

Chapter 10 Introduction encapsulation of IPv6 packet in IPv4 packet Addressing transmission over IPv4 network as far as needed IP Packet Header ingress router of IPv6 network strips off IPv4 header (end of Autoconfiguration Security Support tunnel) Changes to others configured tunnels [RFC1933] Migration Strategies use next IPv4/IPv6 router as end of tunnel automatic tunnels [RFC1933] using IPv4 compatible addresses IPv4 address can be deduced from IPv6 address newer developments: “6over4” [RFC2529], “6to4” [Internet drafts] exchange of routing and reachability information between IPv6 islands ensure consistency between IPv4 and IPv6 routing

Chapter 10 Header Translation (SIIT) [RFC2765] Introduction translation between IPv4 and IPv6 headers Addressing translation between ICMPv4 and ICMPv6 packets translation of fragment extension header into IPv4 fragment info IP Packet Header temporary allocation of IPv4 address for IPv6 host Autoconfiguration (e.g. via DHCP) Security Support no multicast support Changes to others Migration Strategies NAT-PT: Protocol Translation [RFC2766] NNAT or DSTM temporary allocation of IPv4 address for an IPv6 host (e.g. via DHCP) NNAT server causes reconfiguration of IPv6 host after IPv4 DNS query DSTM Dual Stack Transition Mechanism NAT Network Address Translation NNAT No Network Address Translation Application Level Gateways SIIT Stateless IP/ICMP Translation Firewalls, Proxies statically configured addresses on IPv4 / IPv6 sides allow an institution to run IPv6 internally and communicate externally via IPv4 (or vice versa) © Joachim Charzinski http://www.jcho.de/IPNA/ Information and Communication Networks IPNA Chapter 10 Edition Summer 2004 10-23

Questions replace logo

Chapter 10 10.1 What is the IPv6 IPv4 compatibility address for 129.69.1.72? Introduction 10.2 How many IP addresses do you really need? Consider the case Addressing of 100 addresses per person for 1011 persons on the earth (be IP Packet Header future proof!) and 5 hierarchy levels that only use 10% of their Autoconfiguration capacity. Security Support 10.3 Argue why the Priority and Flow Label fields need to be part of Changes to others the IPv6 header. Migration Strategies 10.4 Argue why the Priority and Flow Label fields should not be part of the IPv6 header. Questions

10.5 Think about questions you would ask your students in an exam.