1 TCOM 512 Course plan TCOM 512 Course plan Fall 2003
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
TCOM 512 Course planTCOM 512 Course plan
Fall 2003
TCOM512 2
Questions for first class?Questions for first class?
What is a protocol? What is an API (application programming interface) ? Why the concept of layering? End-to-end argument
TCOM512 3
Why is communication important?Why is communication important?
Resource sharing:– unique resources
– location specific
Load sharing:– performance
– economy of scale
– reliability
Information sharing:– Communication
TCOM512 4
Human protocol vs Computer network protocol:A series of functions performed at different locations.
Hi
Get lost??
Got thetime?
2:00
TCP connection req.
TCP connectionreply.Get http://www.rpi.edu/index.htm
<file>time
What are protocols ?What are protocols ?
Hi
TCOM512 5
Protocols and protocol implementations Protocols and protocol implementations
Building blocks of a network architecture Each protocol object has two different interfaces
– service interface: defines operations on this protocol
– peer-to-peer interface: defines messages exchanged with peer
service interface
peer interface
Li+1 Li+1
LiLi
TCOM512 6
What is Layering?What is Layering?
A technique to organize a system into a succession of logically distinct entities, such that the service provided by one entity is solely based on the service provided by the previous (lower level) entity
Decomposition of a complex system into an ordered series of distinct abstractions
Layering: – Service: what a layer does (e.g. message delivery)
– Interface: how to use the service
– Protocol: how the service is implemented
– Protocol stack: collection of protocols implementing a series of layers
TCOM512 7
Divide and conquerDivide and conquerAnalogy: Organization of air travelAnalogy: Organization of air travel
Protocols: a series of functions performed at different locations
Brd. pass (purchase)
baggage (check)
gates (load)
runway takeoff
airplane routing
Brd. pass (complain)
baggage (claim)
gates (unload)
runway landing
airplane routing
airplane routing
TCOM512 8
Organization of air travel: Organization of air travel: a different viewa different view
Layers: each layer implements a service– via its own internal-layer actions
– relying on services provided by layer below
Brd.pass (purchase)
baggage (check)
gates (load)
runway takeoff
airplane routing
Brd. pass (complain)
baggage (claim)
gates (unload)
runway landing
airplane routing
airplane routing
interface
TCOM512 9
LayeredLayered air travel: air travel: servicesservices
Counter-to-counter delivery of person+bags
baggage-claim-to-baggage-claim delivery
people transfer: loading gate to arrival gate
runway-to-runway delivery of plane
airplane routing from source to destination
Similarly, we organize computer systems into a bunch of layers!Each layer has a protocol to talk to its peer
TCOM512 10
DistributedDistributed implementation of layers implementation of layers
ticket (purchase)
baggage (check)
gates (load)
runway takeoff
airplane routing
ticket (complain)
baggage (claim)
gates (unload)
runway landing
airplane routing
airplane routing
Dep
art
ing
air
port
arr
ivin
g
air
port
intermediate air traffic sites
airplane routing airplane routing
TCOM512 11
EncapsulationEncapsulation
A layer can use only the service provided by the layer immediate below it
Each layer may change and add a header to data packet
data
data
data
data
data
data
data
data
data
data
data
data
data
data
TCOM512 12
Protocol layering and dataProtocol layering and data
Each layer takes data from above adds header information to create new data unit (“encapsulation”) passes new data unit to layer below
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
source destination
M
M
M
M
Ht
HtHn
HtHnHl
M
M
M
M
Ht
HtHn
HtHnHl
message
segment
datagram
frame
TCOM512 13
ISO OSI Reference ModelISO OSI Reference Model
Seven layers– Lower three layers are peer-to-peer
– Next four layers are end-to-end
Application
Presentation
Session
Transport
Network
Datalink
Physical
Application
Presentation
Session
Transport
Network
Datalink
Physical
Network
Datalink
Physical
Physical medium
TCOM512 14
Layering: Layering: logicallogical communication communication
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
networklink
physical
data
dataE.g.: transport take data from app add addressing,
reliability check info to form “datagram”
send datagram to peer wait for peer to ack
receipt analogy: post office
data
transport
transport
ack
(Source: Kurose & Ross)
TCOM512 15
Example: Transport ProtocolExample: Transport Protocol(Physical Communication)(Physical Communication)
(Source: Kurose & Ross)
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
applicationtransportnetwork
linkphysical
networklink
physical
data
data
TCOM512 16
Why Layering?Why Layering?
No layering: each new application has to be re-implemented for every network technology!
Telnet FTP NFS
Packetradio
Coaxial cable
Fiberoptic
Application
TransmissionMedia
HTTP
(FTP – File Transfer Protocol, NFS – Network File Transfer, HTTP – World Wide Web protocol)
TCOM512 17
Why Layering?Why Layering?
Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies
Telnet FTP NFS
Packetradio
Coaxial cable
Fiberoptic
Application
TransmissionMedia
HTTP
Intermediate layer
TCOM512 18
LayeringLayering
Advantages– Modularity – protocols easier to manage and maintain
– Abstract functionality –lower layers can be changed without affecting the upper layers
– Reuse – upper layers can reuse the functionality provided by lower layers
– Encapsulation – functionality in a layer is self-contained;
Disadvantages– Information hiding – inefficient implementations
– Introduces overhead –can lead to intentional layer violations
TCOM512 19
Layered Protocol ArchitectureLayered Protocol Architecture
Protocol = rules and conventions for communication between peers including syntax, semantics, and timing
Service Interface = rules and conventions for communication between clients and service including syntax and timing
Service Model = semantics of interface operations offered by service to clients, and underlying channel characteristics (performance, reliability, etc.)
Recursive: service interface and model implemented internally by protocol
TCOM512 20
Protocols vs. APIsProtocols vs. APIs Protocols
– Needed for interoperability between platforms (possibly built by different vendors)
– A “vertical partitioning” between communicating entities
– Protocols as communicating finite state machines:
– Protocol = Finite State Machine + Message Set
– Specify not only what must be done but how it is done
TCOM512 21
Protocols vs. APIsProtocols vs. APIs APIs
– Needed for portability of software across platforms (from different vendors)
– A “horizontal partitioning” of software on a platform
– Specify only what must be done, not how the implementation does it
– Bottom-up view
– Coalesce related states of the protocol into objects with appropriate methods
– Top-down view
– Define objects that are logical units for the user of the API (i.e., the application or programmer)
– API can be defined without regard to protocols
TCOM512 22
Architectural context for the APIArchitectural context for the API
Local or Remote AccessMechanism (e.g., RMI, CORBA)
Gateways
Application
SIP Adapter
API Implementation
ISUP Adapter
H.323 Adapter ...
API
TCOM512 23
APIsAPIs
Application layer: – JAIN JCC/JCAT, PARLAY, OSA, JTAPI
– Web services : WSDL, UDDI, SOAP
Middleware: – CORBA, MOM, RPC, RMI
Transport: – Sockets, SIP API, JAIN SIP
TCOM512 24
Interface DesignInterface Design
Driven by three factors:– Functionality: what features the customer wants, and is placed at a
level due to e2e principle etc
– Technology: what’s possible. Building blocks and techniques
– Performance: How fast etc… User, Designer, Operator views of performance ..
Interface design crucial because interface outlives the technology used to implement the interface.
TCOM512 25
Layered Protocol ArchitectureLayered Protocol Architecture
Local Area Network
Hos
t 1
Hos
t 2
TELNET
TCP
IP
LAN/MAC
TELNET
TCP
IP
LAN/MAC
Protocols
Interfaces
TCOM512 26
Layered Protocol ArchitectureLayered Protocol ArchitectureService viewService view
Local Area Network
Hos
t 1
Hos
t 2
TELNET
TCP
IP
LAN/MAC
TELNET
TCP
IP
LAN/MAC
Protocols
Interfaces
TCOM512 27
Layered Protocol Architecture ImplementationLayered Protocol Architecture Implementation Layered protocols, from the service point-of-view, are useful
for building more complex systems out of simpler building blocks
… but does not imply that implementations should be strictly layered.
TCOM512 28
How do we architect a network?How do we architect a network?
Layered model– Lots of different problems to solve; complex
– Solved it once --- why solve it again?
– Three distinct aspects:
» Layers of encapsulation
» Layers of services
» Layers of software
Cultural wars:– Computer Systems versus telecommunications
– Least Common Denominator, Best characterization for optimal efficiency
– packets vs. circuits, best-effort vs. reservations,
TCOM512 29
Functionality placement Functionality placement
Which functions belong at which layers?– The end-to-end argument
– Application layer framing (ALF)
30
End to end argument End to end argument
TCOM512 31
Key questionsKey questions
How to decompose the complex system functionality into protocol layers?
What functions to be placed at which levels? Can a function be placed at multiple levels ?
TCOM512 32
Common View of the Telco NetworkCommon View of the Telco Network
Brick
TCOM512 33
Common View of the IP NetworkCommon View of the IP Network
TCOM512 34
End-to-End ArgumentEnd-to-End Argument
“…functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the lower level…”
“…sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement…”
This leads to a philosophy diametrically opposite to the telephone world which sports dumb end-systems (the telephone) and intelligent networks.
TCOM512 35
E2E Argument: InterpretationsE2E Argument: Interpretations
One interpretation: (limited possibly …)– A function can only be completely and correctly implemented with the
knowledge and help of the applications standing at the communication endpoints
Another: (more precise…)– a system (or subsystem level) should consider only functions that can
be completely and correctly implemented within it.
Alternative interpretation: (also correct …)– Think twice before implementing a functionality that you believe that is
useful to an application at a lower layer
– If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement
TCOM512 36
Example: Reliable File TransferExample: Reliable File Transfer
Solution 1: make each step reliable, and then concatenate them
Solution 2: end-to-end check and retry
OS
Appl.
OS
Appl.
Host A Host B
OK
TCOM512 37
DiscussionDiscussion
Solution 1 not complete– What happens if the sender or/and receiver misbehave?
The receiver has to do the check anyway! Thus, full functionality can be entirely implemented at
application layer; no need for reliability from lower layers Is there any need to implement reliability at lower layers? Yes, but only to improve performance Example:
– assume a high error rate on communication network
– then, a reliable communication service at datalink layer might help
TCOM512 38
Trade-offsTrade-offs
Application has more information about the data and the semantic of the service it requires (e.g., can check only at the end of each data unit)
A lower layer has more information about constraints in data transmission (e.g., packet size, error rate)
Note: these trade-offs are a direct result of layering!
TCOM512 39
End-to-End Argument: Critical IssuesEnd-to-End Argument: Critical Issues
The end-to-end principle emphasizes:– function placement
– completeness and
– overall system costs. Philosophy: if application can do it, don’t do it at a lower layer --
application best knows what it needs– add functionality in lower layers iff (1) used by and improves
performances of many applications, (2) does not hurt other applications
– If implementation of function in higher levels is not possible due to technological/economic reasons (eg: telephone network in early 1900s), then it may be placed at lower levels
allows cost-performance tradeoff
TCOM512 40
Performance ImpactPerformance Impact
Consider reliability. Let p be the probability of losing a packet on a link
A n-hop path will result in (1-p)^n prob of successful delivery and prob of loss is 1-(1-p)^n
Assume a path with n=15– Let p=1e-5. Then prob(loss) = 1.5e-5
– Let p=0.01. Prob(loss) = 0.14
TCOM512 41
Internet & End-to-End ArgumentInternet & End-to-End Argument
At network layer provides one simple service: best effort datagram (packet) delivery
Only one higher level service implemented at transport layer: reliable data delivery (TCP)– performance enhancement; used by a large variety of applications
(Telnet, FTP, HTTP) which could provide their own error control
– does not impact other applications (can use UDP)
Everything else implemented at application level
TCOM512 42
Internet & End-to-End ArgumentInternet & End-to-End Argument Discussion: congestion control, flow control: why at transport, rather
than link or application layers?– claim: common functions should migrate down the stack
» Everyone shares same implementation: no need to redo it (reduces bugs, less work, etc…)
» Knowing everyone is doing the same thing, can help
– congestion control too important to leave up to application/user: true but hard to police
» Tcp is “outside” the network; compliance is “optional”
» We do this for fairness (but realize that people could cheat)
– Why flow control in tcp, not (just) in app
» shared tcp buffers at receiver mean want to control flow at tcp level (otherwise unfairness)
» Shared resources is an important reason to push controlling functionality to point at which resources are shared
– Corollary: do active queue management (e.g., RED) in network
TCOM512 43
Key AdvantagesKey Advantages
The IP service can be implemented on top of a large variety of network technologies
Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is – Robust
– Scalable
TCOM512 44
End-to-End Argument: DiscussionEnd-to-End Argument: Discussion
end-end argument emphasizes correctness & completeness, not – complexity: is complexity at edges result in a “simpler” architecture?
– evolvability, ease of introduction of new functionality: ability to evolve because easier/cheaper to add new edge applications than change routers?
– Technology penetration: simple network layer makes it “easier” for IP to spread everywhere
TCOM512 45
Summary: End-to-End ArgumentsSummary: End-to-End Arguments
If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs– add functionality in lower layers iff it is (1) used and improves
performances of a large number of applications, and (2) does not hurt other applications
Success story: Internet
46
Application layer framing Application layer framing
TCOM512 47
Application Layer Framing (ALF)Application Layer Framing (ALF)
Several processing bottlenecks may lie at the “presentation” layer which does not really exist in the TCP/IP stack– These functions are absorbed partially in the transport layer and
partly in the application layer.
– Principle: the application-layer should have control of the syntax and semantics of the presentation conversions
– Transport should provide only common functions
Generalization of ALF: look for elegant ways to allow application visibility/participation in lower-level activities– Eg: QoS – carry application intelligence to the point of QoS
enforcement
TCOM512 48
ALFALF
A concept challenging traditional layering Application needs may not be easily communicated across
layers Idea: Allow application to decide the frame size most
convenient to it Application breaks up data into suitable aggregates The application data units (ADUs) may be processed by the
application in any order Lower layers preserve ADU boundaries Application takes active role in the encapsulation of its data
– Can optimize for loss recovery via intelligent framing and fragmentation
TCOM512 49
Architecture vs Implementation: ALF PrincipleArchitecture vs Implementation: ALF Principle Architecture: decomposition into functional modules,
semantics of modules and syntax used There should be no a priori requirement that the engineering
design of a given system correspond to the architectural decomposition– Eg: layering may not be most effective modularity for
implementation
Summary:– Flexible decomposition
– Defer engineering decisions to implementor.
– Avoid gratuitous implementation constraints
– Maximize engineering options for customization/optimization
TCOM512 50
ILP: Integrated Layer ProcessingILP: Integrated Layer Processing
Modular functionality that is specified in layered form should not be implemented as such
Architecture must minimize gratuitous precedence or ordering constraints …
“Integrated processing loop”– Loop over bytes in packet
– Touch each byte at most once
– Avoid multiple copies within memory
– Massive integrated loop w/ all steps in-line
TCOM512 51
System Design Rules of ThumbSystem Design Rules of Thumb Design a system to tradeoff cheaper resources against
expensive ones (for a gain) When resources are cheap and abundant, waste them. Design
focuses on cutting out any expensive resource that comes in the way! (eg: parallelism)
Apply principles like E2E and ALF to decide on right placement of functionalities in different system levels
Interfaces must outlive several generations of change in the components being interfaced.– Three factors drive interface design:
» functionality demanded,
» available technology,
» performance tradeoff.
TCOM512 52
Functionality requirements can be understood by taking different views of the system (eg: designer, implementor, operator).– Reduced functionality can result in cheaper, scalable, quickly engineered
system
– Placement of functionality is critical in system design
No paradigm is going to work or functionality can be met if the available technology to implement it does not exist.
Performance is either relative or absolute and is usually modeled at the high level as a function from system parameters (input) to system metrics (output). – Metrics must be design to reflect design tradeoffs.
– Only sensitive parameters matter.
Optimize the common case – Solve 90% of the problem that matters, throw away the remaining 10% of the
problem requirements!
System Design Rules of ThumbSystem Design Rules of Thumb
53
Internet design philosophy Internet design philosophy
TCOM512 54
Internet Design Philosophy (Clark’88)Internet Design Philosophy (Clark’88)
Connect existing networks– initially ARPANET and ARPA packet radio network
1. Survivability– ensure communication service even with network and router failures
2. Support multiple types of services3. Must accommodate a variety of networks4. Allow distributed management5. Allow host attachment with a low level of effort6. Be cost effective7. Allow resource accountability
In order of importance:
Different ordering of priorities would make a different architecture!
TCOM512 55
1. Survivability1. Survivability
Continue to operate even in the presence of network failures (e.g., link and router failures)
– as long as network is not partitioned, two endpoints should be able to communicate
– any other failure (excepting network partition) should be transparent to endpoints
Decision: maintain e-e transport state only at end-points– eliminate the problem of handling state inconsistency and performing state
restoration when router fails
Internet: stateless network architecture – No notion of a session/call at network layer
– Grade: A- because convergence times are relatively slow
– BGP takes minutes to coverge
– IS-IS OSPF take ~ 10 seconds
TCOM512 56
2. Types of Services2. Types of Services
Need to support multiple types of services– All combinations of delay, bandwidth, loss
add UDP to TCP to better support other apps – e.g., “real-time” applications
arguably main reason for separating TCP, IP datagram abstraction: lower common denominator on which
other services can be built – service differentiation was considered (remember ToS?), but this has
never happened on the large scale (Why?)
A- proven to allows many applications to be invented and flourish
TCOM512 57
3. Variety of Networks3. Variety of Networks
Very successful (why?) – because the minimalist service; it requires from underlying network
only to deliver a packet with a “reasonable” probability of success
…does not require:– reliability
– in-order delivery
The mantra: IP over everything– Then: ARPANET, X.25, DARPA satellite network..
– Now: ATM, SONET, WDM…
A: can’t name a link layer technology that IP doesn’t run over (carrier pigeon RFC)
TCOM512 58
Other GoalsOther Goals
Allow distributed management– Administrative autonomy: IP interconnects networks
» each network can be managed by a different organization
» different organizations need to interact only at the boundaries
» … but this model complicates routing
– A for implementation, B for concept (disagreement)
Cost effective – sources of inefficiency
» header overhead
» retransmissions
– …but “optimal” performance never been top priority
– A
TCOM512 59
Other Goals (Cont)Other Goals (Cont)
Low cost of attaching a new host– not a strong point higher than other architecture because the
intelligence is in hosts (e.g., telephone vs. computer)
– bad implementations or malicious users can produce considerably harm (remember fate-sharing?)
– C: but things are improving with dhcp, autocofigurations. Looks like a higher grade in future
Accountability– Internet gets an “F”
TCOM512 60
Internet protocol stackInternet protocol stack application: supporting network applications
– ftp, smtp, http
transport: host-host data transfer– tcp, udp
network: routing of datagrams from source to destination– ip, routing protocols
link: data transfer between neighboring network elements– ppp, ethernet
physical: bits “on the wire”
application
transport
network
link
physical
TCOM512 61
Reference ModelsReference Models for Layering for Layering
Application
Presentation
Session
Transport
Network
Datalink
Physical
Application
Transport
Internetwork
Host to Network
FTP
TCP
IP
Ethernet
Telnet HTTP
UDP
PacketRadio
Point-to-Point
TCP/IP Model OSI Ref ModelTCP/IP Protocols
TCOM512 62
Internet (IP) ArchitectureInternet (IP) Architecture
“Hourglass” Not strict layering
TELNET FTP TFTP NTP
TCP UDP
IP
Ethernet Wireless ArpaNet 1822 Serial
TCOM512 63
Internet applicationsInternet applications Variations on three themes
– distinguish protocol vs. application behavior Messaging
– datagram model no direct confirmation of final receipt
– email (optional confirmation now) and IM
– emphasis on interoperation (SMS, pagers, …)
– delays measured in minutes Retrieval & query (request/response)
– “client-server”
– ftp, HTTP
– RPC (Sun RPC, DCE, DCOM, Corba, XML-RPC, SOAP)
– emphasis on fast & reliable transmission
– delays measured in seconds
TCOM512 64
Internet applications, cont’dInternet applications, cont’d
Continuous media– generation rate ~ delivery rate ~ rendering rate
– audio, video, measurements, control
» Internet telephony
» Multimedia conferencing
– related: streaming media slightly longer timescales for rate matching
» video-on-demand
– emphasis is on timely and low-loss delivery real-time
– delays measured in milliseconds
TCOM512 65
Internet protocolsInternet protocols
Protocols support these applications:– data delivery
» HTTP, ftp data part, SMTP, IMAP, POP, NFS, SMB, RTP– identifier mapping (id id, id data)
» ARP, DNS, LDAP– configuration (= specialized version of identifier data)
» DHCP, ACAP, SLP, NETCONF, SNMP– control and setup
» RTSP, SIP, ftp control, RSVP, SNMP, BGP and routing protocols May be integrated into one protocol or general service function
(“middleware”?)
TCOM512 66
History of networkingHistory of networking
History of networking = non-network applications migrate– postal & intracompany mail, fax email, IM
– broadcast: TV, radio
– interactive voice/video communication VoIP
– information access web, P2P
– disk access iSCSI, Fiberchannel-over-IP
TCOM512 67
Network evolutionNetwork evolution
Only three modes, now thoroughly explored:– packet/cell-based
– message-based (application data units)
– session-based (circuits)
Replace specialized networks– left to do: embedded systems
» need cost(CPU + network) < $10
» cars
» industrial (manufacturing) control
» commercial buildings (lighting, HVAC, security; now LONworks)
» remote controls, light switches
» keys replaced by biometrics
TCOM512 68
New applicationsNew applications
New bandwidth-intensive applications– Reality-based networking
– (security) cameras
Distributed games often require only low-bandwidth control information– current game traffic ~ VoIP
Computation vs. storage vs. communications– communications cost has decreased less rapidly than storage costs
TCOM512 69
Transition of networkingTransition of networking
Maturity cost dominates– can get any number of bits anywhere, but at considerable cost and
complexity
– casually usable bit density still very low
Specialized commodity– installed and run by 'amateurs'
– need low complexity, high reliability
TCOM512 70
Security challengesSecurity challenges
DOS, security attacks permissions-based communications– only allow modest rates without asking
– effectively, back to circuit-switched
Higher-level security services more application-layer access via gateways, proxies, …
User identity– problem is not availability, but rather over-abundance
TCOM512 71
ScalingScaling
Scaling is only backbone problem Depends on network evolution:
– continuing addition of AS to flat space deep trouble
– additional hierarchy
TCOM512 72
Quality of Service (QoS)Quality of Service (QoS)
QoS is meaningless to users care about service availability reliability as more and more value depends on network services, can't
afford random downtimes
TCOM512 73
Textbook Internet vs. real InternetTextbook Internet vs. real Internet
end-to-end (application only in 2 places)
middle boxes (proxies, ALGs, …)
permanent interface identifier (IP address)
time-varying (DHCP)
globally unique and routable network address translation (NAT)
multitude of L2 protocols (ATM, ARCnet, Ethernet, FDDI, modems, …)
dominance of Ethernet, but also L2’s not designed for networks (1394 Firewire, Fibre Channel, MPEG2, …)
TCOM512 74
Textbook Internet vs. real InternetTextbook Internet vs. real Internet
mostly trusted end users hackers, spammers, con artists, pornographers, …
small number of manufacturers, making expensive boxes
Linksys, Dlink, Netgear, …, available at Radio Shack
technical users, excited about new technology
grandma, frustrated if email doesn’t work
4 layers (link, network, transport, application)
layer splits
transparent network firewalls, L7 filters, “transparent proxies”
TCOM512 75
Internet architecture documents (readings-hw)Internet architecture documents (readings-hw)
http://www.ietf.org/rfc/rfcXXXX.txt RFC 1287 RFC 2101 RFC 2775 RFC 3234
TCOM512 76
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
The Internet The Internet Protocol Protocol
HourglassHourglass(Deering)(Deering)
TCOM512 77
Why the hourglass architecture?Why the hourglass architecture?
Why an internet layer?– make a bigger network
– global addressing
– virtualize network to isolate end-to-endprotocols from network details/changes
Why a single internet protocol?– maximize interoperability
– minimize number of service interfaces Why a narrow internet protocol?
– assumes least common network functionalityto maximize number of usable networks
Deering, 1998
TCOM512 78
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP + mcast
+ QoS +...
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Putting on Putting on WeightWeight
• requires more functionality from underlying networks
TCOM512 79
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP4 IP6
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Mid-Life Mid-Life CrisisCrisis
• doubles number of service interfaces
• requires changes above & below
• major interoper-ability issues
TCOM512 80
Layer splittingLayer splitting
Traditionally, L2 (link), L3 (network = IP), L4 (transport = TCP), L7 (applications)
Layer 2: Ethernet PPPoE (DSL) Layer 2.5: MPLS, L2TP Layer 3: tunneling (e.g., GPRS) Layer 4: UDP + RTP Layer 7: HTTP + real application
TCOM512 81
Layer violationsLayer violations
Layers offer abstraction avoid “Internet closed for renovation” Cost of information hiding Cost of duplication of information when nothing changes
– fundamental design choice of Internet = difference between circuit and datagram-oriented networks
Assumption: packets are large and getting larger– wrong for games and audio
Cost prohibitive on wireless networks– will see: 10 bytes of payloads, 40 bytes of packet header
– header compression compress into state index on one link
TCOM512 82
Internet acquires presentation layerInternet acquires presentation layer
All learn about OSI 7-layer model OSI: ASN.1 as common rendering of application data
structures– used in LDAP and SNMP (and H.323)
Internet never really had presentation layer– approximations: common encoding (TLV, RFC 822 styles)
Now, XML as the design choice by default
TCOM512 83
Internet acquires session layerInternet acquires session layer
Originally, meant for data sessions Example (not explicit): ftp control connection Now, separate data delivery from session setup
– address and application configuration
– deal with mobility
– will see as RTSP, SIP and H.323
TCOM512 84
But that was yesterday
……. what about tomorrow?
TCOM512 85
What About the Future?What About the Future?
Datagram not the best abstraction for:– resource management,accountability, QoS
new abstraction: flow (see IPv6)– but no one knows what a flow is
routers require to maintain per-flow state state management: recovering lost state is hard here we see the first proposal of “soft state”!
– soft-state: end-hosts responsible to maintain the state
TCOM512 86
Rethinking Internet DesignRethinking Internet Design
What’s changed? operation in untrustworthy world
– endpoints can be malicious
– If endpoint not trustworthy, but want trustworthy network -> more mechanism in network core
more demanding applications
– end-end best effort service not enough
– new service models in network (Intserv, diffserv)?
– new application-level service architecture built on top of network core (e.g., CDN, p2p)?
TCOM512 87
Rethinking Internet DesignRethinking Internet Design
What’s changed? ISP service differentiation
– ISP doing more (than other ISPs) in core is competitive advantage
Rise of third party involvement
– interposed between endpoints (even against will)
– e.g., Chinese gov’t, US recording industry
less sophisticated users
All five changes motivate shift away from end-end!
TCOM512 88
Technical response to changesTechnical response to changes
Trust: emerging distinction between what is “in” network (us, trusted) and what is not (them, untrusted).
– ingress filtering
– emergence of Internet UNI (user network interface, as in ATM)?
Modify endpoints
– Harden endpoints against attack
– Endpoints do content filtering: Net-nanny
– CDN, ASPs: rise of structured, distributed applications in response to inability to send content (e.g., multimedia, high bw) at high quality
TCOM512 89
Technical response to changesTechnical response to changes
Add functions to the network core:
– filtering firewalls
– application-level firewalls
– NAT boxes
– active networking
… All operate within network, making use of application-level information
– which addresses can do what at application level?
– If addresses have meaning to applications, NAT must “understand” that meaning
TCOM512 90
Summary: Internet ArchitectureSummary: Internet Architecture
packet-switched datagram network IP is the glue (network layer
overlay) IP hourglass architecture
– all hosts and routers run IP
stateless architecture– no per flow state inside network
IP
TCP UDP
ATM
Satellite
Ethernet
IP hourglass
TCOM512 91
Summary: Minimalist ApproachSummary: Minimalist Approach
Dumb network– IP provide minimal functionalities to support connectivity
– addressing, forwarding, routing
Smart end system– transport layer or application performs more sophisticated functionalities
– flow control, error control, congestion control
Advantages– accommodate heterogeneous technologies (Ethernet, modem, satellite, wireless)
– support diverse applications (telnet, ftp, Web, X windows)
– decentralized network administration
TCOM512 92
Two ways of constructing a software design:
1)make it so simple that there are obviously no deficiencies, and
2)make it so complicated that there are no obvious deficiencies
--- CAR Hoare
TCOM512 93
Readings Readings
Reading: Saltzer, Reed, Clark: "End-to-End arguments in System Design" Reading: Clark: "The Design Philosophy of the DARPA Internet Protocols":
94
StandardizationStandardization
Henning Schulzrinne
Dept. of Computer Science
Columbia University
Fall 2003
TCOM512 95
StandardsStandards Mandatory vs. voluntary
– Allowed to use vs. likely to sell
– Example: health & safety standards UL listing for electrical appliances, fire codes Telecommunications and networking always focus of standardization
– 1865: International Telegraph Union (ITU)
– 1956: International Telephone and Telegraph Consultative Committee (CCITT) Five major organizations:
– ITU for lower layers, multimedia collaboration
– IEEE for LAN standards (802.x)
– IETF for network, transport & some applications
– W3C for web-related technology (XML, SOAP)
– ISO for media content (MPEG)
TCOM512 96
Who makes the rules? - ITUWho makes the rules? - ITU
ITU = ITU-T (telecom standardization) + ITU-R (radio) + development– http://www.itu.int
– 14 study groups
– produce Recommendations:
» E: overall network operation, telephone service (E.164)
» G: transmission system and media, digital systems and networks (G.711)
» H: audiovisual and multimedia systems (H.323)
» I: integrated services digital network (I.210); includes ATM
» V: data communications over the telephone network (V.24)
» X: Data networks and open system communications
» Y: Global information infrastructure and internet protocol aspects
TCOM512 97
ITUITU
Initially, national delegations Members: state, sector, associate
– Membership fees
Now, mostly industry groups doing work Initially, mostly (international) telephone services Now, transition from circuit-switched to packet-switched universe &
lower network layers (optical) Documents cost SFr, but can get three freebies for each email address
TCOM512 98
IETFIETF
IETF (Internet Engineering Task Force)– see RFC 3233 (“Defining the IETF”)
Formed 1986, but earlier predecessor organizations (1979-) RFCs date back to 1969 Initially, largely research organizations and universities, now mostly R&D labs of
equipment vendors and ISPs International, but 2/3 United States
– meetings every four months
– about 300 companies participating in meetings
» but Cisco, Ericsson, Lucent, Nokia, etc. send large delegations
TCOM512 99
IETFIETF Supposed to be engineering, i.e., translation of well-understood technology standards
– make choices, ensure interoperability
– reality: often not so well defined Most development work gets done in working groups (WGs)
– specific task, then dissolved (but may last 10 years…)
– typically, small clusters of authors, with large peanut gallery
– open mailing list discussion for specific problems
– interim meetings (1-2 days) and IETF meetings (few hours)
– published as Internet Drafts (I-Ds)
» anybody can publish draft-somebody-my-new-protocol» also official working group documents (draft-ietf-wg-*)» versioned (e.g., draft-ietf-avt-rtp-10.txt)» automatically disappear (expire) after 6 months
TCOM512 100
IETF processIETF process
WG develops WG last call IETF last call approval (or not) by IESG publication as RFC
IESG (Internet Engineering Steering Group) consists of area directors – they vote on proposals– areas = applications, general, Internet, operations and management, routing,
security, sub-IP, transport
Also, Internet Architecture Board (IAB) – provides architectural guidance
– approves new working groups
– process appeals
TCOM512 101
RFCsRFCs
Originally, “Request for Comment” now, mostly standards documents that are well settled published RFCs never change always ASCII (plain text), sometimes PostScript anybody can submit RFC, but may be delayed by review (“end run
avoidance”) see April 1 RFCs (RFC 1149, 3251, 3252) accessible at http://www.ietf.org/rfc/ and http://www.rfc-editor.org/
TCOM512 102
IETF process issuesIETF process issues
Can take several years to publish a standard– see draft-ietf-problem-issue-statement
Relies on authors and editors to keep moving– often, busy people with “day jobs” spurts three times a year
Lots of opportunities for small groups to delay things Original idea of RFC standards-track progression:
– Proposed Standard (PS) = kind of works
– Draft Standard (DS) = solid, interoperability tested (2 interoperable implementations for each feature), but not necessarily widely used
– Standard (S) = well tested, widely deployed
TCOM512 103
IETF process issuesIETF process issues
Reality: very few protocols progress beyond PS– and some widely-used protocols are only I-Ds
In addition: Informational, Best Current Practice (BCP), Experimental, Historic
Early IETF: simple protocols, stand-alone– TCP, HTTP, DNS, BGP, …
Now: systems of protocols, with security, management, configuration and scaling– lots of dependencies wait for others to do their job
TCOM512 104
Other Internet standards organizationsOther Internet standards organizations
ISOC (Internet Society)– legal umbrella for IETF, development work
IANA (Internet Assigned Numbers Authority)– assigns protocol constants
NANOG (North American Network Operators Group) (http://www.nanog.org)– operational issues
– holds nice workshop with measurement and “real world” papers
RIPE, ARIN, APNIC– regional IP address registries dole out chunks of address space to ISPs
– routing table management
TCOM512 105
ICANNICANN
Internet Corporation for Assigned Names and Numbers– manages IP address space (at top level)
– DNS top-level domains (TLD)
» ccTLD: country codes (.us, .uk, …)
» gTLDs (.com, .edu, .gov, .int, .mil, .net, and .org)
» uTLD (unsponsored): .biz, .info, .name, and .pro
» sTLD (sponsored): .aero, .coop, and .museum
actual domains handled by registrars
TCOM512 106
Introduction to IETF (readings-hw)Introduction to IETF (readings-hw)
http://www.ietf.org/rfc/rfcXXXX.txt RFC 2026 RFC 2028 RFC 3160 RFC 3869
Related Documents
