Transcript Standardization

Standardization
Henning Schulzrinne
Dept. of Computer Science
Columbia University
Fall 2003
Time Line of the Internet
•Source: Internet Society
2
Standards

Mandatory vs. voluntary
–
–

Telecommunications and networking always focus of standardization
–
–

Allowed to use vs. likely to sell
Example: health & safety standards UL listing for electrical appliances,
fire codes
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)
Who 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
ITU


Initially, national delegations
Members: state, sector, associate
–




Membership fees (> 10,500 SFr)
Now, mostly industry groups doing work
Initially, mostly (international) telephone services
Now, transition from circuit-switched to packetswitched universe & lower network layers (optical)
Documents cost SFr, but can get three freebies for
each email address
IETF

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
IETF

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
IETF 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
IETF activities








general (3): ipr, nomcom, problem
applications (25): crisp, geopriv, impp, ldapbis, lemonade, opes,
provreg, simple, tn3270e, usefor, vpim, webdav, xmpp
internet (18) = IPv4, IPv6, DNS, DHCP: dhc, dnsext, ipoib,
itrace, mip4, nemo, pana, zeroconf
oam (22) = SNMP, RADIUS, DIAMETER: aaa, v6ops, netconf,
…
routing (13): forces, ospf, ssm, udlr, …
security (18): idwg, ipsec, openpgp, sasl, smime, syslog, tls,
xmldsig, …
subip (5) = “layer 2.5”: ccamp, ipo, mpls, tewg
transport (26): avt (RTP), dccp, enum, ieprep, iptel, megaco,
mmusic (RTSP), nsis, rohc, sip, sipping (SIP), spirits, tsvwg
RFCs







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/
IETF process issues

Can take several years to publish a standard
–

Relies on authors and editors to keep moving
–


see draft-ietf-problem-issue-statement
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
IETF process issues

Reality: very few protocols progress beyond PS
–


In addition: Informational, Best Current Practice
(BCP), Experimental, Historic
Early IETF: simple protocols, stand-alone
–

and some widely-used protocols are only I-Ds
TCP, HTTP, DNS, BGP, …
Now: systems of protocols, with security,
management, configuration and scaling
–
lots of dependencies  wait for others to do their job
Other Internet standards organizations

ISOC (Internet Society)
–

IANA (Internet Assigned Numbers Authority)
–

assigns protocol constants
NANOG (North American Network Operators Group)
(http://www.nanog.org)
–
–

legal umbrella for IETF, development work
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
ICANN

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
Modern Internet architecture &
technology
Advanced Internet Services
Dept. of Computer Science
Columbia University
Henning Schulzrinne
Fall 2003
Internet applications

Variations on three themes
–

Messaging
–
–
–
–

distinguish protocol vs. application behavior
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
Internet applications, cont’d

Continuous media
–
–
generation rate ~ delivery rate ~ rendering rate
audio, video, measurements, control


–
related: streaming media slightly longer timescales for
rate matching

–
–
–
Internet telephony
Multimedia conferencing
video-on-demand
emphasis is on timely and low-loss delivery  real-time
delays measured in milliseconds
focus of this course
Internet protocols

Protocols support these applications:
–
data delivery

–
identifier mapping (id  id, id  data)

–
DHCP, ACAP, SLP, NETCONF, SNMP
control and setup


ARP, DNS, LDAP
configuration (= specialized version of identifier  data)

–
HTTP, ftp data part, SMTP, IMAP, POP, NFS, SMB, RTP
RTSP, SIP, ftp control, RSVP, SNMP, BGP and routing
protocols
May be integrated into one protocol or general
service function (“middleware”?)
Networking is getting into middle
years
idea
current
IP
1969, 1980?
1981
TCP
1974
1981
telnet
1969
1983
ftp
1980
1985
Standardization

Really two facets of standardization:
1.
2.
public, interoperable description of protocol, but
possibly many (Tanenbaum)
reduction to 1-3 common technologies



LAN: Arcnet, tokenring, ATM, FDDI, DQDB, … 
Ethernet
WAN: IP, X.25, OSI  IP
Have reached phase 2 in most cases, with
RPC (SOAP) and presentation layer (XML)
most recent 'conversions'
Technologies at ~30 years

Other technologies at similar maturity level:
–
–
–
–
air planes: 1903 – 1938 (Stratoliner)
cars: 1876 – 1908 (Model T)
analog telephones: 1876 – 1915 (transcontinental
telephone)
railroad: 1800s -- ?
Observations on progress

1960s: military  professional  consumer
–

Oscillate: convergence  divergence
–
–

now, often reversed
continued convergence clearly at physical layer
niches larger  support separate networks
Communications technologies rarely disappear (as
long as operational cost is low):
–
exceptions:


–
telex, telegram, semaphores  fax, email
X.25 + OSI, X.400  IP, SMTP
analog cell phones
History 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
Network 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
New applications

New bandwidth-intensive applications
–
–

Distributed games often require only low-bandwidth
control information
–

Reality-based networking
(security) cameras
current game traffic ~ VoIP
Computation vs. storage vs. communications
–
communications cost has decreased less rapidly than
storage costs
Commercial access cost (T1)
$700
$600
$/month
$500
$400
$300
$200
$100
$0
1996
1998
2000
Year
2001
T1
2002
2003
Transit cost (OC-3, NY – London)
Disk storage cost (IDE)
Cost
$100,000.00
$/GB
$10,000.00
$1,000.00
$100.00
$10.00
$1.00
May-79
Feb-82
Nov-84
Aug-87
May-90
Jan-93
Date
Oct-95
Jul-98
Apr-01
Jan-04
Transition 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
–
–
–
OPEX (= people) dominates
installed and run by 'amateurs'
need low complexity, high reliability
Security challenges

DOS, security attacks  permissions-based
communications
–
–


only allow modest rates without asking
effectively, back to circuit-switched
Higher-level security services  more applicationlayer access via gateways, proxies, …
User identity
–
problem is not availability, but rather over-abundance
Scaling


Scaling is only backbone problem
Depends on network evolution:
–
–
continuing addition of AS to flat space  deep
trouble
additional hierarchy
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
Textbook Internet vs. real Internet
end-to-end (application
only in 2 places)
permanent interface
identifier (IP address)
globally unique and
routable
multitude of L2 protocols
(ATM, ARCnet, Ethernet, FDDI,
modems, …)
middle boxes (proxies,
ALGs, …)
time-varying (DHCP)
network address
translation (NAT)
dominance of Ethernet, but
also L2’s not designed for
networks (1394 Firewire, Fibre
Channel, MPEG2, …)
Textbook 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”
Internet architecture documents
(readings)





http://www.ietf.org/rfc/rfcXXXX.txt
RFC 1287
RFC 2101
RFC 2775
RFC 3234
The
Internet
Protocol
Hourglass
(Deering)
email WWW phone...
SMTP HTTP RTP...
TCP UDP…
IP
ethernet PPP…
CSMA async sonet...
copper fiber radio...
Why the hourglass architecture?

Why an internet layer?
–
–
–

Why a single internet protocol?
–
–

make a bigger network
global addressing
virtualize network to isolate end-to-end
protocols from network details/changes
maximize interoperability
minimize number of service interfaces
Why a narrow internet protocol?
–
assumes least common network functionality
to maximize number of usable networks
Deering, 1998
Putting
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
MidLife
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 interoperability issues
Layer 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
Layer violations



Layers offer abstraction  avoid “Internet closed for renovation”
Cost of information hiding
Cost of duplication of information when nothing changes
–

Assumption: packets are large and getting larger
–

fundamental design choice of Internet = difference between circuit
and datagram-oriented networks
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
Internet acquires presentation layer


All learn about OSI 7-layer model
OSI: ASN.1 as common rendering of
application data structures
–

Internet never really had presentation layer
–

used in LDAP and SNMP (and H.323)
approximations: common encoding (TLV, RFC
822 styles)
Now, XML as the design choice by default
Internet 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