What comes next in Internet infrastructure: quality of service, IPv6,

and moreBrian E Carpenter

Program Director, Internet Standards & Technology, IBM

Co-Chair, Differentiated Services WG, IETF

Previous Chair, Internet Architecture Board, IETF

October 2000

Topics

• How the network used to be, how it is, and how it needs to be.

• Is there an integration strategy for QOS?• What QOS solutions do we have?• What’s still missing for QOS?• IPv6• Tactical solutions today• Conclusion

How the network used to be

• IP addresses were plentiful• All packets flowed “best effort” unchanged end to

end• Reliability and security depended (by design) only

on the two end systems of a session.• Loss caused by congestion was corrected by TCP;

TCP slowed down automatically to reduce congestion.

• Real time (UDP) services collapsed during congestion.

How the network is today

• Addresses are scarce– Widespread use of Network Address Translators (NAT)

means that packets are changed by the network. NATs are the enemy of end to end functionality and end to end security, and a management nightmare.

• Security via firewalls– Packets are blocked

• Sessions intercepted by gateways, proxies, and “level 4” switches– Packets are hijacked

• Transparency is lost & congestion is chronic.

How the network needs to be

• Congestion is inherent both during the growth phase (engineers cannot keep up) and the stable phase (marginal cost effect). Therefore, Quality of Service technology is essential.

• Some transparency is gone for ever, but we have to get rid of the NATs. Therefore, IPv6 is essential.

QOS Integration: Almost everything is connected to almost everything else– Routing affects performance– Addressing affects routing– Choice of ISP affects addressing– ISP performance affects choice of ISP– Performance affects user behavior– User behavior affects load– Load affects congestion– Congestion affects performance– Performance affects web sites visited– Web sites visited affect web site survival– …

Routingtopology Addressing

Which ISP?ISP

performance

Web siteperformance

Userbehavior

LoadCongestion

Web sitesvisited

Siteprofitability

ISPprofitability

Protocolsused

QOS technology

Trafficengineering

What strategies have any chance?

• Since everything is connected to everything, and the interactions are non-linear, it is very unlikely that we can design an integrated solution with any assurance that it will succeed.

• We need some guiding principles, but apart from that we have to focus on highly modular technology and an evolutionary approach.

• There isn’t going to be an architecture blueprint any time soon.

Some guiding principles (1)

• Single points of failure are bad. Single points of failure hidden inside the network are even worse.

• Make it so that communication fails only when one or both end-systems fail.– Routes and routers must be redundant– Minimize dependencies such as firewalls, proxies,

applications gateways, & translation/transcoding boxes.– If functionality is distributed, allow for automatic

fallback to other copies.

Some guiding principles (2)

• Simple, scaleable solutions are better than complex, monolithic ones.– Minimize use of options– Minimize dependencies– Minimize need for per-flow state information

Some guiding principles (3)

• There’s too much fog on the Internet today, caused by chronic shortage of address space and the resulting use of ambiguous (“private”) addresses and temporary addresses. You’re never quite sure what you’re talking to or where it is.– This makes rational QOS policy management hard.– The only known way to get more addresses any time

soon is to deploy IPv6.

Common features of all QOS solutions

Source

Destination

Ingress router

Egress router

Classifier & admission control

Offered load

Policy system

One service class per microflow

Sourceapplication

Destinationapplication

Ingress router

Egress router

admission control

Millions of microflows = millions of service classes(e.g. one per phone call)

Integrated Services

RSVP

A few pre-defined service classes

Source

Destination

Ingress router

Egress router

[admission control]

Many microflows share one service class(e.g. all phone calls in one class)

Differentiated services

One model of a policy system

Server Server

RouterRouter

QOS policy manager

Policy repository database

GUI

LDAP

LDAPSNMP,COPS, telnet

Policy enforcement points

Policy definition point

Policy information model

Summary of QOS components

• Integrated Services / RSVP

• Differentiated Services

• DiffServ/IntServ integration

• QOS support at lower layers (ATM, 802, MPLS)

• SNMP, COPS, MIBs and PIBs

• LDAP, policy information model

Missing QOS components (1)

• Receiver capability- how does sender or QOS system know what a receiver can absorb in a DiffServ environment?

• Generally, how does an application discover end-to-end QOS requirement?

• API for DiffServ as well as IntServ.

• Robust mechanism for path QOS discovery.

Missing QOS components (2)

• Inter-domain QOS signalling• Traffic Engineering for QOS; QOS routing

redux.• Congestion control for real-time flows.• Generally agreed QOS

measurement/accounting techniques.• Field experience, best current practices,

inter-ISP QOS SLAs.

IPv6

• Increased size of address space (128 bits)• Simplified autoconfiguration of addresses• Improved support for site renumbering• Strong security (IPsec) mandatory to implement• Increased flexibility for supporting new options• Simplified header format for fast processing• Simplified Mobile IP design

IPv6 Industry Timeline

1980 1990 95 2000 2010

IPv4 Web IPv6 Sun ships, stable invented design Cisco, Microsoft starts state intent to ship; (IBM stable standards a leader) Internet growth

spurt begins; scalinglimits appear.

Wireless Internet growth spurt

IPv0-3 were early R&D.IPv5 was failed R&D.

IPv6 widespread

AIX ships;CS/390 download

Legacy IPv4-only client

or server

New IPv6-only client or server

IPv4network

IPv6 network

Application proxy

Dual Host

directtranslatedIPv6 encapsulated in IPv4

Middleware

IPv4 IPv6stack stack

Coexistence Mechanisms

IPv4/IPv6translator

Middleware

IPv6 IPv4stack stack

Dual Host

Application proxy server

(dual IPv4/IPv6)

IPv4Internet

IPv6wirelessInternet

IPv4 servers

IPv4clients

Pervasive IPv6Clients

Wireless IPv6 scenariowith IPv4 legacy

IPv6server

IBM End-to-End Focus Areas:IBM Microelectronics Division

Network Processor; integrating IPv6 in hardwareIBM Global Services

Consulting and education; to enable IPv6 adoptionPartnerships

Teaming with cross-industry leadersIBM Global Telecommunications Industry Group

End-to-end solution opportunities with carriersLinux

IBM leadership in the Linux open source communityOperating Systems (AIX, OS/390, AS/400)

TCP/IP stack integrationApplications & Middleware enablement

WebSphere, Lotus, Tivoli, CICS, IMS, DB2, and MQ Series

IPv6: A Cross-IBM and Industry Initiative

IBM Committed to IPv6 across its product lines

IBM eServer pSeries (AIX & RS/6000) First commercial Unix IPv6 implementation available in October 1997Ongoing enhancements

IBM eServer zSeries (Communications Server for OS/390) IPv6 demo download available in July 1998

HTTP://www-4.ibm.com/software/network/commserver/downloads/demos/demo_csos390.html

API mappings beginning with CS for OS/390 V2R6

IBM IPv6 Product Overview

Tactical solutions today (1)

• QOS not deployed Network is congested move data nearer to user replicate data in edge servers Content Distribution Networks such as Akamai network appliances (future) distributed e-business applications.

• In this area the open Internet will lead and drive the enterprise market.

Tactical solutions today (2)

• Network is not transparent “Walled Garden” model (such as i-Mode or WAP) proxy, server, and content adaptation boxes.

• Network is not transparent cannot deploy network level security use transport level or applications level security.

Not mentioned…• MMPLS – new technology for path switching

through IP carrier infrastructure• OOptical switching – will this just speed up the

backbone, or will it replace the “everything over IP” mantra?

• GGRID computing and other approaches to peer-to-peer computing – will client/server cease to dominate?

Conclusions

• No grand plan for QOS; no single, integrated architecture that suits all QOS-dependent applications.

• Basic QOS tools are defined but several integration mechanisms are still missing.

• The time for IPv6 is about 2 years away.• Meanwhile, Silicon Valley continues to get

rich with pragmatic short-term solutions.