Transcript Standardization - Computer Science, Columbia University

Standardization
Henning Schulzrinne
Dept. of Computer Science
Columbia University
Spring 2008
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