View
215
Download
1
Embed Size (px)
Citation preview
Slide 2
Outline
• Background
• Best-Effort Architecture
• Emerging Architectures
• Conclusions
• References
Slide 3
Background
• Origins of today’s Internet– US Dept. of Defense DARPA projects (1960-70’s)– Evolved from defense to research to commercial
• What is the Internet?– Hierarchical, global network of communicating hosts– Hosts have addresses, routers interconnect hosts– Routers perform packet switching, “best-effort” service
• What is IP (Internet Protocol)?– Suite of protocols/framework to control routers/hosts– Addressing, routing, registration, etc.
Slide 4
Background
IP network domains
Eth
Campus LAN
Sample Network
Various router link technologies (SONET/SDH, ATM, FR)
Residential Internet (modem access)
Intra-domain OSPF routing
Mux
Corporate networks
Inter-domain BGP routing (red)
IP routers perform hop-by-hop
packet forwarding
Slide 5
Background
• Tremendous growth of IP-based networks– Worldwide deployment, many TCP/IP applications– Hosts is growing exponentially, only few “on-line”– Improving, cheaper “end-user” access technologies
Link speeds increasing (cable, DSL, wireless)– “Capacity requirements doubling per 4 months” (1999)– Becoming crucial to economic/national infrastructure
• Changing networking paradigms: “circuit to packet”– Packet data volume has overtaken voice volume– Shift from “data over voice” to “voice over data”– “Convergent network” philosophy
I.e., “One network carries all (data, voice, video)”
Slide 6
Background
Time1997 1998 1999 2000 2001
Rel
ativ
e T
raff
ic
Voice
Packet data
Internet applications:web browsing/caching, ftp, telnet (exponential growth scales)
Residential, business trunked voice circuits (linear growth scales)
Data traffic on large carrier networks exceeds voice circuit traffic (1998-1999)
Slide 7
Background
• Traditional IP user applications– Initial “data” applications (telnet, ftp, email,web)– “Non-realtime” applications, no service guarantees
E.g., Web (ftp) transfer can take 1ms or 10 sec
• New, emerging IP user applications – Recently, new “real-time” applications
E.g., voice (IP telephony), IP video– Future explosion of “multi-media” applications
E.g., Internet gaming, tele-commuting/conferencing
– Applications need services “guarantees”E.g., Voice<10 ms delay, video<100 ms delay
Slide 8
Background
• Challenges– Internet must evolve to support new applications– IP protocols must support service guarantees
I.e., packet delay, loss, jitter – Must also support today’s IP protocols/applications
I.e., “Backwards compatibility” requirement
• New solutions are required– “Intelligent” switching technologies
I.e., Selective processing of traffic flows/types– Capable of supporting large, diverse user base
I.e., Commonly termed “scalability”– Various proposals have been made
Slide 9
Best-Effort Architecture
• Represents traditional Internet architecture– “Hop-by-hop” forwarding (routing decision per packet)– Very rudimentary packet buffering capabilities
“First-in-first-out” (FIFO), G/G/1 model– Routing protocols for packet route control (static)
Open-shortest-path-first (OSPF) intra-domainBorder-gateway protocol (BGP) inter-domain
• Best suited for “non-realtime” data applications– High delay tolerance (e.g., ftp, email)– Reliability via higher-layer transport (TCP/IP)– Works well for lightly-loaded networks
I.e., Reduced packet losses, delays
Slide 10
Physical Layer
SONET SONET
Best-Effort Architecture
ATMHardware (electronic buffering processing or SONET-type opto-electronic switching)
“Best-effort” services (e.g., web-browsing, ftp, telnet)
Transport control, reliable transfer functions
Traditional “best-effort” layer three addressing, routing, packet forwarding
Variety of data and link layer technologies (costs, complexity)
Traditional IP Network Hierarchy
FR
SONET Ethernet
IP (Network)
TCP/UDP (Transport)
User Applications
Slide 11
Best-Effort Architecture
• Inadequate service definition– Basic queueing gives no “quality of service” (QoS)
E.g., bandwidth (capacity), delay, loss, etc.– No service differentiation possible– Router processing speeds become bottleneck
I.e., “Layer 3” IP address-lookup ( O(log2(N) )
– Static routing causes network congestion
• Inefficient interworking with multiple “lower-layers”– Layered model approach (SONET/SDH, ATM, FR)
Added maintenance/operations costs, complexity – Counter to convergent networks trend
Slide 12
Best-Effort Architecture
Voice packet stream (phone call)
FIFO Queueing Node (Edge)
Data packet stream (web transfer)
Constant inter-packet timing, fixed packet size
Time
Variable inter-packet timing, variable packet sizes
Time
FIFO queue, voice and data packets mix (G/G/1 model)
Fixed router transmission link speed
IP Router
Outgoing (combined) flows: voice timing very distorted
Incoming (individual) traffic flows to IP router queue
Time
Slide 13
FIFO Queueing Network
Router B
Router A
Router C
Router D
Full-IP address lookup, single aggregate with large interference
between multiple flows
User connection flows (e.g., TCP/IP or UDP session, dotted lines) buffered in same queues
Best-Effort Architecture
Slide 14
Emerging Architectures
• Revamp IP protocols/architecture– New service definitions for “integrated” services
“Everything over IP networks” (voice, video, data)– Basic idea is to “separate out” different traffic types
I.e., Treat “realtime” different from “non-realtime”– Large focus in Internet Engineering Task Force (IETF)
• Multiple proposals have emerged:– Integrated Services (IntServ) proposal– Differentiated Services (DiffServ) proposal– Multi-Protocol Label Switching (MPLS)*
*Emerging as comprehensive solution
Slide 15
Emerging Architectures: IntServ
• Detailed, advanced service definitions – Multiple service categories
Best-effort: Like “best-effort” Internet
Controlled-load: Lightly-loaded Internet
Guaranteed: Firm bounds (capacity, delay)
• Router requirements– Advanced, fast packet classification/processing
I.e.,IP-address lookup, complex buffering/scheduling– Admission control, scheduling, buffer management– Advanced resource control signaling (RSVP protocol)
For set-up and take-down of flow reservations– Requires policy control (who makes reservations?)
Slide 16
Emerging Architectures: IntServ
Voice packet streams
Per-Flow Queueing Node (Edge)
Data packet streams
Constant inter-packet timing, fixed packet size
Time
Variable inter-packet timing, variable packet sizes
Time
Per-flow buffering, voice and data packets separated (G/G/n model)
Fixed link speed
IP IntServ Router
Outgoing (combined) flows: limited voice timing distortion
Time
Time
Time
Per-flow bandwidth scheduler gives capacity guarantees
(hardware complexity: tracking, processing/computing)
Flow 1
Flow 4
Flow 3
Flow 2
Slide 17
Emerging Architectures: IntServPer-Flow Queueing Network
IntServ Router B
IntServ Router A
IntServ Router C
IntServ Router D
Per-flow buffering and scheduling, complexity increases with number of traversing flows
User connection flow (e.g., TCP/IP or UDP session)
Slide 18
Emerging Architectures: IntServ
• Shortcomings and concerns– Per-user flow storage/processing for QoS at routers
I.e., Potentially millions of flows at any time– Hardware complexity: storage, scheduling, monitoring
E.g., Very fast (bounded) IP-address lookup times– Software complexity: RSVP protocol– Does not “scale”, i.e., if number of flows very large
Note: Same problem as ATM technology– Traffic engineering limitations
• Current status/developments– Complexity concerns have led to DiffServ proposal– RSVP being modified to suit DiffServ and MPLS
Slide 19
Emerging Architectures: DiffServ
• Simplify per-flow model to per-class– Arrange (mark) user flow packets into classes “Class
of service” (CoS) indicated in IP header– Perform “per-class” control (buffering, scheduling)
Via standardized “per-hop behaviors” (PHBs)– Much less complex than “per-flow” IntServ approach
I.e., O(# of classes) vs. O(# of flows)
• Router requirements– Edge classification/metering (“mark” ToS byte header)– PHB resource mappings (% bandwidth,priority,buffer)
E.g., Advanced buffer control (RED schemes)– No signaling, “fixed” service level agreements (SLAs)
Slide 20
Emerging Architectures: DiffServ
Voice packet streams
Per-Class Queueing Node (Edge)
Data packet streams
Constant inter-packet timing, fixed packet size
Time
Variable inter-packet timing, variable packet sizes
Time
DiffServ classification maps multiple flows to fewer classes (two shown) by
“marking” ToS byte in IPv4 header
Fixed link speed
IP DiffServ Router Outgoing (combined) flows: moderate voice timing distortion
Time
Time
Time
Per-class bandwidth scheduler (reduced complexity)
Class 1
Class 2
1 1 1 1
2 2
Slide 21
Emerging Architectures: DiffServPer-Class Queueing Network
DiffServ Router B
DiffServ Router A
DiffServ Router C
DiffServ Router D
Per-class buffering/scheduling, complexity reduced to number of
classes not number of traversing flows
User connection flows (e.g., TCP/IP or UDP session, dotted lines) mapped to fewer classes
Slide 22
Emerging Architectures: DiffServ
• Traffic aggregation problems– Class guarantees do not mean flow (user) guarantees
I.e., Flows inside a class can “collide/interfere”– Good for small data transfers (web browsing)– Poor performance for real-time flows
• Limited flexibility – Designed for relatively “static” networks
Network topology, user traffic demands unchanging– Difficult to change class resource allocations
E.g., Increase/decrease bandwidth per usage levels– Automated, fast re-adjustment required today
I.e., Need “traffic engineering” applications
Slide 23
Emerging Architectures: MPLS
• Very comprehensive framework– Decouple packet forwarding from routing
I.e., packet route setup before data transfer– Major industry focus (main IP networking framework)
• Based upon earlier flow/tag switching proposals– Assign “tags” to flows, switch based upon “tags”– Reduced delays for (layer 3) IP address-lookups– Various tag assignment schemes (measure/control)
• MPLS enables many advanced applications– Traffic engineering, QoS service guarantees/routing– Virtual private networks (VPNs)
Slide 24
Physical Layer
Emerging Architectures: MPLS
IP-MPLS Network Hierarchy
IP-MPLS (Network/Data)
Hardware (electronic packet buffering/processing and even optical switching)
TCP/UDP (Transport)
User Applications
“QoS-based” applications (IP voice/video, Internet gaming, etc.), and traditional “best-effort” applications (web browsing, ftp, telnet, etc.)
Transport control, reliable transfer functions
Layer three “QoS-aware” routing/packet forwarding and label-based forwarding, traffic engineering, protection/ restoration
Slide 25
Emerging Architectures: MPLS
• “Label” and “label switched path” (LSP) concepts– Label: Identifier/tag used for switching data flows– LSP: Concatenation of labels, arbitrary granularity– LSP achieves “virtual circuit”, i.e., logical connection– Encapsulate IP packets into MPLS packets (header)– LSP protection, label stacking (flow aggregation)
• Router requirements– Maintain input/output label tables, “short” label match– Generic association of labels with local QoS resources
I.e., buffer space, priority, bandwidth– Signaling protocols to control label assignments
RSVP+extensions, label distribution protocol (LDP)
Slide 26
Emerging Architectures: MPLS
Voice packet streams
MPLS Label-Switching Node
Data packet streams
Constant inter-packet timing, fixed packet size
Time
Variable inter-packet timing, variable packet sizes
Time
MPLS packet mapping (via forward equivalent class, FEC), packet
encapsulation with MPLS header
Fixed link speed
IP MPLS Router
Voice distortion dependant upon MPLS resource control (e.g.,
per-flow or per-class)
Time
Time
Time
Generic resource control engine
(buffering, scheduling)
Lab
el e
ncap
sula
tion
, la
bel s
wap
ping
Label encapsulated user packets/datagrams (i.e., MPLS
“shim” header)
Slide 27
Lab
el c
ontr
ol
Resource controlL
abel
con
trol
Resource control
Emerging Architectures: MPLSMPLS Network
MPLS Router B
MPLS Router A
MPLS Router C
MPLS Router D
Label processing operations (edge mapping, swapping,
stacking): arbitrary granularity and resource control
User connection flow (e.g., TCP/IP or UDP session)
Lab
el c
ontr
ol
Resource control
Lab
el c
ontr
ol
Resource control
Label-switched paths (incoming labels overwritten with outgoing
labels after switching, based upon label table entries)
Link In Label In Link Out Label Out
1 23 3 21
2 15 5 27
… … … …
5 3 1 89
Label Table
Slide 28
• DiffServ implementation via MPLS– Associate labels (LSPs) with aggregate classes
I.e., Multiple flows (traffic classes) on to same label– RSVP/LDP can now fill signaling shortcomings
• IntServ implementation via MPLS– Associate labels (LSPs) with each flow (connection)
I.e., Each user (connection) has unique label (LSP)– Note: Per-flow complexity, but can “stack” labels
• Extensions to optical networks– For migration from SONET/SDH technology– Can apply “label” switching to wavelength switching
Emerging Architectures: MPLS
Slide 29
Conclusions
• Internet growth forecasted to grow tremendously– New applications, more bandwidth, more users– Increasingly integral to corporate/national success
• Traditional “best-effort” IP model is inadequate– Designed for “latent” data traffic transport (ftp, email)– No multi-service guarantees (delay, loss, jitter)– Added costs complexity maintaining multiple networks
I.e., IP, ATM, SONET/SDH, frame relay, etc.
• Emerging advances promise much more– Service guarantees, traffic engineering, VPNs– MPLS has emerged as comprehensive framework