Title: TCOM 512 Course plan
1TCOM 512 Course plan
2Questions for first class?
- What is a protocol?
- What is an API (application programming
interface) ? - Why the concept of layering?
- End-to-end argument
3Why is communication important?
- Resource sharing
- unique resources
- location specific
- Load sharing
- performance
- economy of scale
- reliability
- Information sharing
- Communication
4What are protocols ?
- Human protocol vs Computer network protocol
- A series of functions performed at different
locations.
Hi
TCP connection req.
Get lost??
Hi
5Protocols 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
Li1
Li1
service interface
Li
Li
peer interface
6What 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
7Divide and conquerAnalogy Organization of air
travel
- Protocols a series of functions performed at
different locations
8Organization of air travel a different view
interface
- Layers each layer implements a service
- via its own internal-layer actions
- relying on services provided by layer below
9Layered air travel services
Counter-to-counter delivery of personbags baggag
e-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
10Distributed implementation of layers
ticket (purchase) baggage (check) gates
(load) runway takeoff airplane routing
ticket (complain) baggage (claim) gates
(unload) runway landing airplane routing
arriving airport
Departing airport
intermediate air traffic sites
11Encapsulation
- 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
12Protocol 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
source
destination
message
segment
datagram
frame
13ISO OSI Reference Model
- Seven layers
- Lower three layers are peer-to-peer
- Next four layers are end-to-end
Application
Application
Presentation
Presentation
Session
Session
Transport
Transport
Network
Network
Network
Datalink
Datalink
Datalink
Physical
Physical
Physical
Physical medium
14Layering logical communication
- E.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
transport
transport
(Source Kurose Ross)
15Example Transport Protocol(Physical
Communication)
(Source Kurose Ross)
16Why Layering?
(FTP File Transfer Protocol, NFS Network File
Transfer, HTTP World Wide Web protocol)
FTP
NFS
Telnet
Application
Coaxial cable
Fiber optic
Transmission Media
- No layering each new application has to be
re-implemented for every network technology!
17Why Layering?
- Solution introduce an intermediate layer that
provides a unique abstraction for various network
technologies
FTP
NFS
Telnet
Application
Intermediate layer
Coaxial cable
Fiber optic
Transmission Media
18Layering
- 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
19Layered 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
20Protocols 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
21Protocols 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
22Architectural context for the API
Application
Local or Remote Access Mechanism (e.g., RMI,
CORBA)
API
Gateways
23APIs
- Application layer
- JAIN JCC/JCAT, PARLAY, OSA, JTAPI
- Web services WSDL, UDDI, SOAP
- Middleware
- CORBA, MOM, RPC, RMI
- Transport
- Sockets, SIP API, JAIN SIP
24Interface Design
- Driven by three factors
- Functionality what features the customer wants,
and is placed at a level due to e2e principle etc - Technology whats 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.
25Layered Protocol Architecture
TELNET
TELNET
Interfaces
Host 1
TCP
TCP
Host 2
Protocols
IP
IP
LAN/MAC
LAN/MAC
Local Area Network
26Layered Protocol ArchitectureService view
TELNET
TELNET
Interfaces
Host 1
TCP
TCP
Host 2
Protocols
IP
IP
LAN/MAC
LAN/MAC
Local Area Network
27Layered 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.
28How 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,
29Functionality placement
- Which functions belong at which layers?
- The end-to-end argument
- Application layer framing (ALF)
30End to end argument
31Key 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 ?
32Common View of the Telco Network
Brick
33Common View of the IP Network
34End-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.
35E2E 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
36Example Reliable File Transfer
Host A
Host B
Appl.
Appl.
OS
OS
- Solution 1 make each step reliable, and then
concatenate them - Solution 2 end-to-end check and retry
37Discussion
- 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
38Trade-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!
39End-to-End Argument Critical Issues
- The end-to-end principle emphasizes
- function placement
- completeness and
- overall system costs.
- Philosophy if application can do it, dont 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
40Performance 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 n15
- Let p1e-5. Then prob(loss) 1.5e-5
- Let p0.01. Prob(loss) 0.14
41Internet 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
42Internet 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
43Key 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
44End-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
45Summary End-to-End Arguments
- If the application can do it, dont 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
46Application layer framing
47Application 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
48ALF
- 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
49Architecture 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
50ILP 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
51System 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.
52System Design Rules of Thumb
- 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!
53Internet design philosophy
54Internet Design Philosophy (Clark88)
In order of importance
- Connect existing networks
- initially ARPANET and ARPA packet radio network
- Survivability
- ensure communication service even with network
and router failures - Support multiple types of services
- Must accommodate a variety of networks
- Allow distributed management
- Allow host attachment with a low level of effort
- Be cost effective
- Allow resource accountability
Different ordering of priorities would make a
different architecture!
551. 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
562. 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
573. 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 cant name a link layer technology that IP
doesnt run over (carrier pigeon RFC)
58Other 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
59Other 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
60Internet 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
61Reference Models for Layering
TCP/IP Model
OSI Ref Model
TCP/IP Protocols
Application
FTP
Telnet
HTTP
Transport
TCP
UDP
Internetwork
IP
Host to Network
Ethernet
PacketRadio
Point-to-Point
62Internet (IP) Architecture
- Hourglass
- Not strict layering
63Internet 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
64Internet applications, contd
- 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
65Internet 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?)
66History 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
67Network 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) lt 10
- cars
- industrial (manufacturing) control
- commercial buildings (lighting, HVAC, security
now LONworks) - remote controls, light switches
- keys replaced by biometrics
68New 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
69Transition 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
70Security 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
71Scaling
- Scaling is only backbone problem
- Depends on network evolution
- continuing addition of AS to flat space ? deep
trouble - additional hierarchy
72Quality 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
73Textbook Internet vs. real Internet
74Textbook Internet vs. real Internet
75Internet architecture documents (readings-hw)
- http//www.ietf.org/rfc/rfcXXXX.txt
- RFC 1287
- RFC 2101
- RFC 2775
- RFC 3234
76The Internet Protocol Hourglass(Deering)
77Why 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
78Putting on Weight
email WWW phone... SMTP HTTP RTP... TCP
UDP IP mcast QoS ... ethernet PPP CSMA
async sonet... copper fiber radio...
- requires more functionality from underlying
networks
79Mid-Life Crisis
email WWW phone... SMTP HTTP RTP... TCP
UDP IP4 IP6 ethernet PPP CSMA
async sonet... copper fiber radio...
- doubles number of service interfaces
- requires changes above below
- major interoper-ability issues
80Layer 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
81Layer 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
82Internet 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
83Internet 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
84- But that was yesterday
- . what about tomorrow?
85What 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
86Rethinking Internet Design
- Whats changed?
- operation in untrustworthy world
- endpoints can be malicious
- If endpoint not trustworthy, but want trustworthy
network -gt 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)?
87Rethinking Internet Design
- Whats 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 govt, US recording industry
- less sophisticated users
All five changes motivate shift away from end-end!
88Technical 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
89Technical 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
90Summary 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
TCP
UDP
IP
Satellite
ATM
Ethernet
IP hourglass
91Summary 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
92- Two ways of constructing a software design
- make it so simple that there are obviously no
deficiencies, and - make it so complicated that there are no obvious
deficiencies - --- CAR Hoare
93Readings
- Reading Saltzer, Reed, Clark "End-to-End
arguments in System Design" - Reading Clark "The Design Philosophy of the
DARPA Internet Protocols"
94Standardization
- Henning Schulzrinne
- Dept. of Computer Science
- Columbia University
- Fall 2003
95Standards
- 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)
96Who 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
97ITU
- 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
98IETF
- 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 RD 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
99IETF
- 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
100IETF 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
101RFCs
- 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/
102IETF 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
103IETF 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
104Other 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
105ICANN
- 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
106Introduction to IETF (readings-hw)
- http//www.ietf.org/rfc/rfcXXXX.txt
- RFC 2026
- RFC 2028
- RFC 3160
- RFC 3869