Transcript No Slide Title

What comes next in Internet
infrastructure: quality of
service, IPv6, and more
Brian 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
…
Traffic
engineering
ISP
profitability
Routing
topology
Addressing
User
behavior
Which ISP?
ISP
performance
Web site
performance
Congestion
Protocols
used
Load
QOS technology
Web sites
visited
Site
profitability
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
Policy system
Classifier &
admission control
Source
Ingress
router
Offered load
Egress
router
Destination
One service class per microflow
admission control
Source
application
Ingress
router
Millions of microflows =
millions of service classes
(e.g. one per phone call)
Integrated Services
RSVP
Egress
router
Destination
application
A few pre-defined service classes
[admission control]
Source
Ingress
router
Many microflows share
one service class
(e.g. all phone calls in one class)
Differentiated
services
Egress
router
Destination
One model of a policy system
Policy
information
model
GUI
Policy
repository
database
QOS policy
manager
LDAP
SNMP,
COPS,
telnet
LDAP
Server
Policy definition
point
Server
Policy enforcement points
Router
Router
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
IPv4
stable
1990
95
Web
invented
IPv6
Sun ships,
design Cisco, Microsoft
starts
state intent to ship;
(IBM
stable standards
IPv6
a leader)
widespread
Internet growth
spurt begins; scaling
limits appear.
IPv0-3 were early
R&D.
IPv5 was failed R&D.
2000
2010
Wireless Internet
AIX ships;
growth spurt
CS/390 download
direct
translated
IPv6 encapsulated in IPv4
Coexistence
Mechanisms
Legacy
IPv4-only client
or server
Dual Host
Dual Host
IPv4
network
Middleware
IPv6
stack
IPv4
stack
Application
proxy
Middleware
IPv4
stack
IPv4/IPv6
translator
IPv6
network
New IPv6-only
client or server
IPv6
stack
IPv6: A Cross-IBM and Industry
Initiative
IBM End-to-End Focus Areas:
IBM Microelectronics Division
Network Processor; integrating IPv6 in hardware
IBM Global Services
Consulting and education; to enable IPv6 adoption
Partnerships
Teaming with cross-industry leaders
IBM Global Telecommunications Industry Group
End-to-end solution opportunities with carriers
Linux
IBM leadership in the Linux open source community
Operating Systems (AIX, OS/390, AS/400)
TCP/IP stack integration
Applications & Middleware enablement
WebSphere, Lotus, Tivoli, CICS, IMS, DB2, and MQ Series
IBM IPv6 Product Overview
IBM Committed to IPv6 across its product lines
IBM eServer pSeries (AIX & RS/6000)
First commercial Unix IPv6 implementation available in October 1997
Ongoing 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
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 peerto-peer computing – will client/server cease to
dominate?
Conclusions
• No grand plan for QOS; no single,
integrated architecture that suits all QOSdependent 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.