Transcript ppt - The Fengs

CSE 524: TCP/IP Internetworking
Protocols
Wu-chang Feng
1
CSE524: Lecture 1
Overview, Internet architecture
2
Quiz
• How much do you know?
3
Syllabus
• http://www.cse.ogi.edu/class/cse524/
• TA
– Guangzhi Liu [email protected]
– Office hours:
• Thursday 3pm-6pm
• CSE Central 146
• Required book
– Kurose/Ross, “Computer Networking: A TopDown Approach Featuring the Internet”
4
Syllabus
• Grading
– Exams
• 25% Midterm (10/29/2001: Chapters 2, 3)
• 25% Final (11/28/2001: Chapters 1, 4, 5)
– Other
• 25% Research paper (12/5/2001)
• 25% Homework, quizzes, class participation
• Coarse-grained grading
5
Research paper
• You become the expert on “X”. You teach me.
–
–
–
–
–
–
Current survey and projected future of “X”
“X” not covered in course
Any length, no more than 10 pages
Topic and scope negotiated by e-mail
Approval by 10/29/2001, Due by 12/5/2001
Topics I’d like to know more about
• Ultra-wide band, sensor networks, high-speed switching and
routing products, web switching products, peer-to-peer
networks, content-addressable networks, overlay networks,
IPv6, mobile IP, intrusion detection systems, IP traceback,
DDoS attacks, DDoS prevention, MPLS, lambda switching,
Internet worms, …
6
Research paper
• Grading
– Correctness
– Completeness
• Content
• References
– Originality
• Each paper will be “Google” tested
• Quoting and referencing is fine
• Wholesale copying is not
7
Goals of course
• Higher-level design decisions and their
impact
• Encyclopedia of essential protocols and
algorithms
8
Outline of course
• Internet architecture, history, future
(Chapter 1)
• Physical, data-link layers (Chapter 5)
• Network layer (Chapter 4)
• Transport layer (Chapter 3)
• Application layer (Chapter 2)
9
About the course
• Extremely condensed
• Not comprehensive
– Hundreds of protocols
– PSU/OCATE 510 - Internet Routing
– PSU/OCATE 510 - Network
Management/Security
– OHSU 58X - Multimedia Networking
– OHSU 58X – Internet Technology and
Research
10
Internet Architecture
•
•
•
•
•
•
•
•
http://www.nap.edu/html/coming_of_age/
http://www.ietf.org/rfc/rfc1958.txt
Packet switching over circuit switching
“Hourglass” design
End-to-end architecture
Layering of functionality
Distributed design, decentralized control
Superior organizational process
11
The Network Core
• mesh of interconnected
routers
• the fundamental question:
how is data transferred
through net?
– circuit switching:
dedicated circuit per call:
telephone net
– packet-switching: data
sent thru net in discrete
“chunks”
12
Network Core: Circuit Switching
Resources reserved for
“call” on an end to end
basis
• link bandwidth, switch
capacity
• dedicated resources: no
sharing
• circuit-like (guaranteed)
performance
• call setup required
13
Network Core: Circuit Switching
network resources (e.g.,
bandwidth) divided into
“pieces”
• pieces allocated to calls
• resource piece idle if not
used by owning call (no
sharing)
• dividing link bandwidth into
“pieces”
– frequency division
– time division
14
Network Core: Circuit Switching
Example
• 1890-current: Phone network
–
–
–
–
–
Fixed bit rate
Mostly voice
Not fault-tolerant
Components extremely reliable
Global application-level knowledge throughout
network
15
Network Core: Packet Switching
each end-end data stream
divided into packets
• user A, B packets share
network resources
• each packet uses full link
bandwidth
• resources used as needed,
Bandwidth division into
“pieces”
Dedicated allocation
Resource reservation
resource contention:
• aggregate resource
demand can exceed
amount available
• congestion: packets
queue, wait for link use
• store and forward:
packets move one hop
at a time
– transmit over link
– wait turn at next16link
Network Core: Packet Switching
10 Mbs
Ethernet
A
B
statistical multiplexing
C
1.5 Mbs
queue of packets
waiting for output
link
D
45 Mbs
E
17
Network Core: Packet Switching
Example
• 1981-current: Internet network
–
–
–
–
Variable bit rate
Mostly data
Fault-tolerant
Components not extremely reliable (versus
phone components)
– Distributed control and management
18
Packet switching versus circuit switching
Packet switching allows more users to use network!
• 1 Mbit link
• each user:
– 100Kbps when
“active”
– active 10% of time
N users
• circuit-switching:
1 Mbps link
– 10 users
• packet switching:
– with 35 users,
probability > 10 active
less that .004
19
Packet switching versus circuit switching
Is packet switching a “slam dunk winner?”
• Great for bursty data
– resource sharing
– no call setup
• Excessive congestion: packet delay and loss
– protocols needed for reliable data transfer,
congestion control
• Q: How to provide circuit-like behavior?
– bandwidth guarantees needed for audio/video
apps
still an unsolved problem (chapter 6)
20
Hourglass design
21
Hourglass design
• D. Clark, “The design philosophy of the
DARPA internet”, SIGCOMM 1988,
August 16 - 18, 1988.
• http://www.acm.org/pubs/citations/proceedi
ngs/comm/52324/p106-clark/
22
Hourglass design
• Only one protocol at the Internet level
– Minimal required elements at the narrowest point
• IP – Internet Protocol
–
–
–
–
–
http://www.rfc-editor.org/rfc/rfc791.txt
http://www.rfc-editor.org/rfc/rfc1812.txt
Unreliable datagram service
Addressing and connectionless connectivity
Fragmentation and assembly
• Innovation at the edge
– Phone network: dumb edge devices, intelligent network
– Internet: dumb network, intelligent edge devices
23
Hourglass design
• Simplicity allowed fast deployment of multivendor, multi-provider public network
– Ease of implementation
– Limited hardware requirements
– Eventual economies of scale
• Designed independently of hardware
– Hardware addresses decoupled from IP addresses
– IP header contains no data/physical link specific
information
– Allows IP to run over any fabric
24
Hourglass design
• Waist expands at transport layer
• Two dominant services layered above IP
• TCP – Transmission Control Protocol
– Connection-oriented service
– http://www.rfc-editor.org/rfc/rfc793.txt
• UDP – User Datagram Protocol
– Connectionless service
– http://www.rfc-editor.org/rfc/rfc768.txt
25
Hourglass design
• TCP – Transmission Control Protocol
– Reliable, in-order byte-stream data transfer
• Acknowledgements and retransmissions
– Flow control
• Sender won’t overwhelm receiver
– Congestion control
• Senders won’t overwhelm network
26
Hourglass design
• UDP – User Datagram Protocol
– Unreliable data transfer
– No flow control
– No congestion control
27
Hourglass design
• Check out /etc/services on *nix or
C:\WIN*\system32\services
• IANA
– http://www.iana.org/assignments/port-numbers
• What uses TCP?
– HTTP, FTP, Telnet, SMTP, NNTP, BGP
• What uses (mainly) UDP?
– SNMP, NTP, NFS, RTP (streaming media, IP telephony,
teleconferencing), multicast applications
• Many protocols can use both
28
Hourglass design
• Question?
– Are TCP, UDP, and IP enough?
– What other functionality would applications
need?
29
Hourglass design
•
•
•
•
•
•
Security?
Quality-of-service?
Reliable, out-of-order delivery service?
Handling greedy sources?
Accounting and pricing support?
IPsec, DiffServ, SCTP, ….
30
End-to-end principle
• J. H. Saltzer, D. P. Reed and D. D. Clark
“End-to-end arguments in system design”,
Transactions on Computer Systems, Vol. 2,
No. 4, 1984
• http://www.acm.org/pubs/citations/journals/
tocs/1984-2-4/p277-saltzer/
31
End-to-end principle
• Where to put the functionality?
– In the network? At the edges?
• End-to-end functions best handled by endto-end protocols
– Network provides basic service: data transport
– Intelligence and applications located in or close
to devices at the edge
– Violate principle as a performance
enhancement
32
End-to-end principle
• The good
– Basic network functionality allowed for
extremely quick adoption and deployment
using simple devices
• The bad
– New network features and functionality are
impossible to deploy, requiring widespread
adoption within the network
– IP Multicast, QoS
33
Layering
• Modular approach to network functionality
• Example:
Application
Host-to-host connectivity
Link hardware
34
Layering Characteristics
• Each layer relies on services from layer below and
exports services to layer above
• Interface defines interaction
• Hides implementation - layers can change without
disturbing other layers (black box)
• Examples
–
–
–
–
Topology and physical configuration
Routing
Applications require no knowledge of this
New applications deployed without coordination with
network operators or operating system vendors
35
Protocols
• Module in layered structure
• Set of rules governing communication
between network elements (applications,
hosts, routers)
• Protocols define:
– Interface to higher layers (API)
– Interface to peer
• Format and order of messages
• Actions taken on receipt of a message
36
Layering
User A
User B
Application
Transport
Network
Link
Host
Host
Layering: technique to simplify complex systems
37
Layer Encapsulation
User A
User B
Get index.html
Connection ID
Source/Destination
Link Address
38
E.g.: OSI Model: 7 Protocol Layers
•
•
•
•
•
•
•
Physical: how to transmit bits
Data link: how to transmit frames
Network: how to route packets
Transport: how to send packets end2end
Session: how to tie flows together
Presentation: byte ordering, security
Application: everything else
39
OSI Layers and Locations
Application
Presentation
Session
Transport
Network
Data Link
Physical
Host
Switch
Router
Host
40
Example: Transport Layer
• First end-to-end layer
• End-to-end state
• May provide reliability, flow and congestion
control
41
Example: Network Layer
• Point-to-point communication
• Network and host addressing
• Routing
42
Layering
• Is Layering always good?
– Sometimes..
• Layer N may duplicate lower level functionality
(e.g., error recovery)
• Layers may need same info (timestamp, MTU)
• Strict adherence to layering may hurt performance
43
Layering
• Need for exposing underlying layers for optimal
application performance
– D. Tennenhouse and D. Clark. Architectural
Considerations for a New Generation of Protocols.
SIGCOMM 1990.
• Intel employees: Tennenhouse is a networking “rock star” and
your head of research
– Application Layer Framing (ALF)
• Enable application to process data as soon as it can
• Expose application processing unit (ADU) to protocols
– Integrated Layer Processing (ILP)
• Layering convenient for architecture but not for
implementations
• Combine data manipulation operations across layers
44
Distributed design and control
• Reliability from intelligent aggregation of
unreliable components
• Alternate paths, adaptivity, lack of
centralized control
• Each network owned and managed
separately
• Exception: TLDs and TLD servers, IP
address allocation (ICANN)
45
Superior organizational process
• IAB/IETF process allowed for quick specification,
implementation, and deployment of new standards
–
–
–
–
–
Free and easy download of standards
Rough consensus and running code
2 interoperable implementations
Bake-offs
http://www.ietf.org/
• ISO/OSI
– Comparison to IETF left as an exercise
46
Acknowledgements
• Portions of this lecture and all subsequent
lectures are taken from course slides by
Kurose/Ross and course slides by Srini
Seshan’s Computer Networking course at
http://www.cs.cmu.edu/~srini/15-744/S01/
47