29
Slide 1 Internet-The Next Generation: Developments in Internet Networking Technologies

Slide 1 Internet-The Next Generation: Developments in Internet Networking Technologies

  • View
    215

  • Download
    1

Embed Size (px)

Citation preview

Slide 1

Internet-The Next Generation:

Developments in Internet

Networking Technologies

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