the ietf: standards and non-standards · 11/17/12! 12! ietf - 23! © 1999 scott bradner! internet...

11/17/12

1

IETF - 1 © 1999 Scott Bradner

The IETF:��Standards and non-Standards

Scott Bradner Harvard University

[email protected]


Outline ◆  IETF overview ◆  IETF IP QoS work ◆  smart wires

11/17/12

2


What is the IETF? ◆  an engineering organization ◆  a group of people who solve Internet problems


An Engineering Organization ◆ vendors ◆ users ◆ network operators ◆  academics ◆  researchers ◆  all as individuals ◆ no membership

11/17/12

3


A Short History of the IETF ◆  initial DARPA research in 1970's using NCP

Telnet file transfer electronic mail

◆ production network definition of Internet Activities Board (IAB) IP4 and TCP deployed 1981-1983 MILNET/ARPANET division 1983


IAB Oversight Period ◆ 1986

Internet Assigned Number Authority (IANA) Internet Research Task Force (IRTF) Internet Engineering Task Force (IETF) some other task forces

◆ 1987 Working groups

◆ 1988 Internet Engineering Steering Group (IESG)

11/17/12

4


IAB Oversight Period, contd. ◆ 1989

dissolution of other task forces ◆ 1992

leadership redefined IAB => "Internet Architecture Board" IESG: manages the IETF & approve standards


1992: Internet Society Oversight ◆ process evolution (poised/poisson)

Standards track detailed - RFC 2026 Intellectual property rights (IPRs) Handling of appeals

◆  Internet Society: interface to outside world Corporate / legal umbrella Evangelism - INET conference Policy areas

11/17/12

5


The Role of IETF in the Development of the Internet ◆ protocol definition ◆  infrastructure issues


Protocol Definition ◆  all infrastructure protocols since 1986 ◆ Examples:

PPP OSPF SNMP HTTP 1.1 ...

11/17/12

6


Infrastructure Issues ◆  routing and addressing

IP6 addressing network address translation BGP policy routing

◆  security IPSEC authentication IPSEC encryption ISAKMP key exchange


Infrastructure Issues, contd. ◆ next generation issues

IP/ATM Label switching

◆ quality of service issues intserv RSVP diffserv

11/17/12

7


The Relationship Between the IETF and Other Standards Bodies ◆  ITU-T ◆ ATM forum ◆  IEEE ◆ W3C ◆ DAVIC ◆  ...


Types of Standards ◆ de jure standards ◆ de facto standards

corporate consortia individual efforts

11/17/12

8


De Jure Bodies ◆  ITU-T ◆  ISO ◆  IEEE ◆ ANSI


Closed Industry Consortia ◆ W3C ◆ DAVIC ◆ ATM Forum ◆ Frame Relay Forum

11/17/12

9


McLuhan’s global village

IETF


IETF “Standards” ◆  standards only because people use them ◆ no formal recognition ◆ no submitting to “traditional” bodies

11/17/12

10


Relationships: ◆  liaisons / representatives

ITU-T, ISO study groups, ATM Forum ... ◆  share people with other organizations

more effective than formal liaisons but confuse other standards organizations

◆ growing area but culture clash IETF is mostly bottoms up

◆ new-work mailing list to pre announce new working groups and BOFs for representatives of other standards groups


The IETF Standards Process

11/17/12

11


Top Level View of Organization

Internet Society

IANA IAB IRTF IETF


Internet Research Task Force (IRTF) ◆  focused on long term problems in Internet

reliable multicast multicast routing congestion management end to end protocols etc.

11/17/12

12


Internet Assigned Number Authority (IANA) ◆  assigns numbers and keeps them from colliding

Protocol numbers IP addresses mostly delegated to IP Address registries

Names mostly delegated to DNS name registries

◆ working out relationship between ICANN & IETF over IANA protocol related functions


Protocol numbers ◆  IP protocol numbers ◆ well known TCP/UDP ports ◆ PPP protocol ids ◆ MIME types ◆  etc.

11/17/12

13


RFC Editor ◆ was Jon Postel et al

now et al ◆  [email protected] ◆  supported by the Internet Society


IETF Chair ◆  chair of IESG ◆  selected by nomcom ◆ director of General Area ◆  ex officio member of IAB ◆ Chief Talking (and traveling) Officer

11/17/12

14


IETF Areas

Applications

Transport

InternetRouting

Internet Engineering

Steering Group

Operations and

ManagementUser Services

Security

General


Area Directors ◆  selected by nomcom ◆ 2 year terms ◆ most Areas have 2 ADs ◆  responsible for setting direction in Area ◆  responsible for managing process in Area

approve BOFs & working groups

11/17/12

15


BOFs ◆ usually precede formation of a Working Group ◆ group of people interested in a topic ◆  convince an AD that they have a good idea - one

worth exploring ◆ need description and agenda before a BOF can be

scheduled ◆ BOFs generally only meet once ◆  can lead to a W��G or can be a one time thing


Working Groups ◆  this is where the IETF primarily get its work done ◆  focused by charter agreed between chair and area

director specific deliverables documents and timetable

◆  approved by IESG with IAB guidance ◆ AD with IESG has final say on charter

11/17/12

16


IETF Areas ◆ Applications Area ◆ General Area ◆  Internet Area ◆ Operations and Management Area ◆ Routing Area ◆ Security Area ◆ Transport Area ◆ User Services Area


General Area ◆  Area director(s)

Fred Baker <[email protected]> ◆  Working groups:

Authentication, Authorization and Accounting (aaa) Policy Framework (policy) Process for Organization of Internet Standards ONgoing (poisson)

11/17/12

17


Applications Area ◆  Area director(s)

Keith Moore <[email protected]>

Patrik Faltstrom <[email protected]> ◆  Working groups:

Application Configuration Access Protocol (acap) Application MIB (applmib) Calendaring and Scheduling (calsch) Common Indexing Protocol (find) Content Negotiation (conneg) DAV Searching and Locating (dasl) Detailed Revision/Update of Message Standards (drums) Electronic Data Interchange-Internet Integration (ediint) Extensions to FTP (ftpext) HyperText Transfer Protocol (http) Instant Messaging and Presence Protocol (impp) Internet Fax (fax)

Internet Open Trading Protocol (trade) Internet Printing Protocol (ipp) LDAP Duplication/Replication/Update Protocols (ldup) LDAP Extension (ldapext) Large Scale Multicast Applications (lsma) MIME Encapsulation of Aggregate HTML Documents (mhtml) Mail and Directory Management (madman) Message Tracking Protocol (msgtrk) NNTP Extensions (nntpext) Printer MIB (printmib) Schema Registration (schema) Telnet TN3270 Enhancements (tn3270e) Uniform Resource Locator Registration Procedures (urlreg) Uniform Resource Names (urn) Usenet Article Standard Update (usefor) WWW Distributed Authoring and Versioning (webdav) Web Replication and Caching (wrec)


Internet Area ◆  Area director(s)

Jeffrey Burgan <[email protected]>

Thomas Narten <[email protected]> ◆  Working groups:

AToM MIB (atommib) DNS IXFR, Notification, and Dynamic Update (dnsind) Dynamic Host Configuration (dhc) Frame Relay Service MIB (frnetmib) IP Over Fibre Channel (ipfc) IP Over IEEE 1394 (ip1394) IP over Cable Data Network (ipcdn) IP over VBI (ipvbi)

IPNG (ipngwg) Interfaces MIB (ifmib) Internetworking Over NBMA (ion) PacketWay (pktway) Point-to-Point Protocol Extensions (pppext)

Service Location Protocol (svrloc)

11/17/12

18


Operations and Management Area ◆  Area director(s)

Randy Bush < [email protected]>

Bert Wijnen <[email protected]> ◆  Working groups:

ADSL MIB (adslmib) Benchmarking Methodology (bmwg) Bridge MIB (bridge) Distributed Management (disman) Entity MIB (entmib) Ethernet Interfaces and Hub MIB (hubmib) G and R for Security Incident Processing (grip) MBONE Deployment (mboned) Network Access Server Requirements (nasreq) Next Generation Transition (ngtrans)

Physical Topology MIB (ptopomib) Remote Authentication Dial-In User Service (radius) Remote Network Monitoring (rmonmib) Roaming Operations (roamops) Routing Policy System (rps) SNMP Agent Extensibility (agentx) SNMP Version 3 (snmpv3) The Internet and the Millennium Problem (2000) Uninterruptible Power Supply (upsmib)


Routing Area ◆  Area director(s)

Rob Coltun <[email protected]> TBA

◆  Working groups: Data Link Switching MIB (dlswmib) General Switch Management Protocol (gsmp) IP Routing for Wireless/Mobile Hosts (mobileip) IS-IS for IP Internets (isis) Inter-Domain Multicast Routing (idmr) Inter-Domain Routing (idr) Mobile Ad-hoc Networks (manet) Multicast Extensions to OSPF (mospf)

Multicast Source Discovery Protocol (msdp) Multiprotocol Label Switching (mpls) Open Shortest Path First IGP (ospf) Protocol Independent Multicast (pim) QoS Routing (qosr) Routing Information Protocol (rip) SNA DLC Services MIB (snadlc) SNA NAU Services MIB (snanau) UniDirectional Link Routing (udlr)

11/17/12

19


Security Area ◆  Area director(s)

Jeffrey Schiller <[email protected]>

Marcus Leech <[email protected]> ◆  Working groups:

An Open Specification for Pretty Good Privacy (openpgp) Authenticated Firewall Traversal (aft) Common Authentication Technology (cat) Domain Name System Security (dnssec) IP Security Protocol (ipsec) Intrusion Detection Exchange Format (idwg) One Time Password Authentication (otp)

Public-Key Infrastructure (X.509) (pkix) One Time Password Authentication (otp) Public-Key Infrastructure (X.509) (pkix) S/MIME Mail Security (smime) Secure Shell (secsh) Simple Public Key Infrastructure (spki) Transport Layer Security (tls) Web Transaction Security (wts)


Transport Area ◆  Area director(s)

Scott Bradner <[email protected]>

Vern Paxson <[email protected]> ◆  Working groups:

Audio/Video Transport (avt) Differentiated Services (diffserv) IP Performance Metrics (ippm) IP Telephony (iptel) Integrated Services (intserv) Integrated Services over Specific Link Layers (issll) Media Gateway Control (megaco) Multicast-Address Allocation (malloc) Multiparty Multimedia Session Control (mmusic)

Network Address Translators (nat) Network File System Version 4 (nfsv4) ONC Remote Procedure Call (oncrpc) PSTN and Internet Internetworking (pint) RSVP Admission Policy (rap) Realtime Traffic Flow Measurement (rtfm) Resource Reservation Setup Protocol (rsvp) Signaling Transport (sigtran) TCP Implementation (tcpimpl) TCP Over Satellite (tcpsat)

11/17/12

20


User Services Area ◆ Area director(s)

April Marine <[email protected]> ◆ Working groups:

Responsible Use of the Network (run) User Services (uswg)


IETF Secretariat ◆  located physically

Corporation for National Research Initiatives (CNRI) Reston Virginia (Washington DC)

◆  runs plenary meetings mailing lists Internet draft directory

◆  coordinates day to day work of IESG and working groups

11/17/12

21


What is a “Request For Comments” (RFC)? ◆ not all RFCs are standards!

though some vendors imply otherwise ◆ many types of RFCs


RFC Repository Contains: ◆  Standards

OSPF ◆  Obsolete Standards

RIPv1 ◆  requirements

Host Requirements ◆  policies

Classless InterDomain Routing ◆  April fool’s day jokes

IP on Avian Carriers

◆  poetry ‘Twas the night before startup

◆  white papers On packet switches with infinite storage

◆  corporate documentation Ascend multilink protocol (mp+)

◆  experimental history Netblt

11/17/12

22


Working Papers ◆  Internet-Draft

random or non-random thoughts input to the process zapped after 6 months all RFCs must pre-exist as IDs


IETF Approval Process ◆  rough consensus

unanimous agreement not required ◆ Working Group “last-call”

two week comment period in working group ◆  IETF “last-call”

two week IETF-wide comment period ◆  IESG review

11/17/12

23


Standards Track Levels: ◆ Best Current Practices (BCP)

generally policies or procedures ◆ Proposed Standard (PS)

good idea, no known problems ◆ Draft Standard (DS)

multiple interoperable implementations ◆ Standard (STD)

wide use

◆ fly before buy


Archives ◆  Informational (FYI) ◆ Experimental ◆ Historical

11/17/12

24


Transport Area QoS Working Groups ◆  Integrated Services (intserv)

guaranteed and controlled load services ◆  Integrated Services over Specific Link Layers

(issll) Intserv for various link types, including ATM

◆ Resource Reservation Setup Protocol (rsvp) signaling protocol for Integrated Services networks may become general IETF signaling protocol


TSV Area QoS Working Groups, contd. ◆ RSVP Admission Policy (rap)

router <-> policy server protocol for RSVP ◆ Differentiated Services (diffserv)

non-flow based QoS protocols ◆  IP Performance Metrics (ippm)

measure performance of networks

11/17/12

25


IEEE Related IETF Work ◆ “IP over foo” - started in 1985

RFC 948 - Two methods for the transmission of IP datagrams over IEEE 802.3 networks (OBS)

RFC 1042 - Standard for the transmission of IP datagrams over IEEE 802 networks (STD)

RFC 1390 - Transmission of IP and ARP over FDDI Networks

RFC 2464 - Transmission of IPv6 Packets over Ethernet Networks

RFC 2470 - Transmission of IPv6 Packets over Token Ring Networks

RFC 2467 - Transmission of IPv6 Packets over FDDI Networks


IEEE Related IETF Work, contd. ◆ MIBs

RFC 1230 - IEEE 802.4 Token Bus MIB RFC 1231 - IEEE 802.5 Token Ring MIB RFC 1368 - Definition of Managed Objects for IEEE

802.3 Repeater Devices RFC 1512 - FDDI Management Information Base RFC 1515 - Definitions of Managed Objects for IEEE

802.3 Medium Attachment Units (MAUs) RFC 1516 - Definitions of Managed Objects for IEEE

802.3 Repeater Devices RFC 1743 - IEEE 802.5 MIB using SMIv2

11/17/12

26


IEEE Related IETF Work, contd. ◆ more MIBs

RFC 1749 - IEEE 802.5 Station Source Routing MIB using SMIv2

RFC 2108 - Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2

RFC 2239 - Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2

RFC 2266 - Definitions of Managed Objects for IEEE 802.12 Repeater Devices


IETF QoS IEEE-Related Work ◆  issll working group is prime focus of QoS work ◆  three Internet-Drafts

A Framework for Providing Integrated Services Over Shared and Switched IEEE 802 LAN Technologies

SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks

Integrated Service Mappings on IEEE 802 Networks

11/17/12

27


Use of IEEE MAC Addresses in IPv6 ◆ RFC 2374 - An IPv6 Aggregatable Global Unicast

Address Format

FP format prefix TLA top-level aggregation identifier res reserved for future use NLA next-level aggregation identifier SLA site-level aggregation identifier interface ID interface identifier

3! 13! 24!8! 16! 64!

NLA! SLA!res!TLA!FP! interface ID!


IPv6 Interface ID ◆ 64 bits ◆ 8-byte (or expanded 6-byte) MAC address of

interface ◆  can also use DHCPv6 ◆ 1st 3 bytes of interface ID

c c c c" c c u g" c c c c" c c c c" c c c c" c c c c"

c = bit of company id u = universal / local bit (complemented) g = individual / group bit

11/17/12

28


Cooperation with Other Standards Groups ◆  ideal - multiple groups work on one protocol

published by one group to prevent out of sync versions e.g. Internet FAX, RTP

◆  real - does not always happen too many groups working in telephony area other groups finding IETF’s area important differences in architectural view IETF has a “stupid network” bias


Smart Wires ◆  in an end to end world, smart link-layers are a

concern ◆ “qos” has different meanings in link-layers

prioritization - e.g. 802.1Q flow control - e.g. ATM ABR

◆ prioritization can be very helpful if packet mapping can cooperate with end-to-end signaling e.g. RSVP & intserv issll is802 work an example

11/17/12

29


Smart Wires Which Know Better ◆  link-level flow control can be an issue ◆  creates layered control systems with different

characteristics at the different layers what is effect on end-to-end flow management of random

(to the ends) changes in apparent link latency? ◆ one answer offered is 1 RTT worth of buffering per

session at entry points may deal with loss but far from clear effect on flow rate


End-to-End is TCP ◆ much of current data traffic is TCP/IP

growing, but still small, amount of UDP (e.g. RTP) some other protocols being worked on

◆ TCP flow control developed over many years ◆ multiple phases

slow start congestion avoidance loss response

◆  effect of a link-layer flow-control has to be understood for each phase

11/17/12

30


Prediction ◆  classical control system theory recommends

against layered control systems ◆  effect on TCP not well known

same for other end-to-end rate control protocols ◆  seems to be more of a research rather than a

standards item today ◆ prediction - data systems will make little use of

link-level flow control systems when end-to-end is longer than a link unless interconnection devices are part of end to end

signaling mechanism


Questions?