Evolution of Internet Standardization: ITU and IETF

1. Standardization Henning Schulzrinne Dept. of Computer Science Columbia University Fall 2003

2. Time Line of the Internet • Source: Internet Society

3. Standards • 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)

4. 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

5. 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 packet-switched universe & lower network layers (optical) • Documents cost SFr, but can get three freebies for each email address

6. 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

7. 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

8. 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

9. 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

10. 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/

11. IETF 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

12. IETF 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

13. Other 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

14. 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

15. Modern Internet architecture & technology Advanced Internet Services Dept. of Computer Science Columbia University Henning Schulzrinne Fall 2003

16. Internet 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

17. Internet 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 • focus of this course

18. Internet 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”?)

19. Networking is getting into middle years

20. Standardization • Really two facets of standardization: • 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'

21. 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 -- ?

22. Observations on progress • 1960s: military  professional  consumer • now, often reversed • Oscillate: convergence  divergence • 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

23. 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

24. 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

25. New 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

26. Commercial access cost (T1)

27. Transit cost (OC-3, NY – London)

28. Disk storage cost (IDE)

29. 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

30. Security 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

31. Scaling • Scaling is only backbone problem • Depends on network evolution: • continuing addition of AS to flat space  deep trouble • additional hierarchy

32. 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

33. Textbook Internet vs. real Internet

34. Textbook Internet vs. real Internet

35. Internet architecture documents (readings) • http://www.ietf.org/rfc/rfcXXXX.txt • RFC 1287 • RFC 2101 • RFC 2775 • RFC 3234

36. The Internet Protocol Hourglass(Deering) email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio...

37. 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

38. 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

39. Mid-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

40. 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

41. Layer 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

42. Internet 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

43. 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