* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Document
Net neutrality law wikipedia , lookup
Point-to-Point Protocol over Ethernet wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Distributed firewall wikipedia , lookup
Computer network wikipedia , lookup
Network tap wikipedia , lookup
Airborne Networking wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
TCP congestion control wikipedia , lookup
Serial digital interface wikipedia , lookup
Internet protocol suite wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Packet switching wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Quality of service wikipedia , lookup
UniPro protocol stack wikipedia , lookup
Internet-The Next Generation: Developments in Internet Networking Technologies Slide 1 Outline • Background • Best-Effort Architecture • Emerging Architectures • Conclusions • References Slide 2 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 3 Background Sample Network Residential Internet (modem access) Campus LAN Corporate networks Mux Eth IP network domains IP routers perform hop-by-hop packet forwarding Intra-domain OSPF routing Various router link technologies (SONET/SDH, ATM, FR) Inter-domain BGP routing (red) Slide 4 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 5 Background Relative Traffic Data traffic on large carrier networks exceeds voice circuit traffic (1998-1999) Internet applications: web browsing/caching, ftp, telnet (exponential growth scales) Residential, business trunked voice circuits (linear growth scales) Packet data Voice 1997 1998 1999 Time 2000 2001 Slide 6 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 7 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 8 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-domain Border-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 9 Best-Effort Architecture Traditional IP Network Hierarchy Transport control, reliable transfer functions User Applications Traditional “best-effort” layer three addressing, routing, packet forwarding TCP/UDP (Transport) “Best-effort” services (e.g., webbrowsing, ftp, telnet) IP (Network) Variety of data and link layer technologies (costs, complexity) ATM FR SONET Ethernet SONET SONET Hardware (electronic buffering processing or SONET-type optoelectronic switching) Physical Layer Slide 10 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 11 Best-Effort Architecture FIFO Queueing Node (Edge) Constant inter-packet timing, fixed packet size Time IP Router Outgoing (combined) flows: voice timing very distorted Voice packet stream (phone call) Time Variable inter-packet timing, variable packet sizes FIFO queue, voice and data packets mix (G/G/1 model) Fixed router transmission link speed Time Data packet stream (web transfer) Incoming (individual) traffic flows to IP router queue Slide 12 Best-Effort Architecture FIFO Queueing Network User connection flows (e.g., TCP/IP or UDP session, dotted lines) buffered in same queues Router B Router D Router A Full-IP address lookup, single aggregate with large interference between multiple flows Router C Slide 13 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 14 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 15 Emerging Architectures: IntServ Per-Flow Queueing Node (Edge) Constant inter-packet timing, fixed packet size IP IntServ Router Outgoing (combined) flows: limited voice timing distortion Time Flow 1 Time Voice packet streams Variable inter-packet timing, variable packet sizes Flow 2 Flow 3 Fixed link speed Flow 4 Per-flow bandwidth scheduler gives capacity guarantees (hardware complexity: tracking, processing/computing) Time Time Data packet streams Time Per-flow buffering, voice and data packets separated (G/G/n model) Slide 16 Emerging Architectures: IntServ Per-Flow Queueing Network User connection flow (e.g., TCP/IP or UDP session) IntServ Router B IntServ Router D IntServ Router A Per-flow buffering and scheduling, complexity increases with number of traversing flows IntServ Router C Slide 17 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 18 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 19 Emerging Architectures: DiffServ Per-Class Queueing Node (Edge) Constant inter-packet timing, fixed packet size Time Time Voice packet streams IP DiffServ Router Class 1 1 1 Variable inter-packet timing, variable packet sizes Time Data packet streams 1 1 Class 2 2 Time Outgoing (combined) flows: moderate voice timing distortion Time Fixed link speed 2 Per-class bandwidth scheduler (reduced complexity) DiffServ classification maps multiple flows to fewer classes (two shown) by “marking” ToS byte in IPv4 header Slide 20 Emerging Architectures: DiffServ Per-Class Queueing Network User connection flows (e.g., TCP/IP or UDP session, dotted lines) mapped to fewer classes DiffServ Router B DiffServ Router D DiffServ Router A Per-class buffering/scheduling, complexity reduced to number of classes not number of traversing flows DiffServ Router C Slide 21 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 22 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 23 Emerging Architectures: MPLS IP-MPLS Network Hierarchy Transport control, reliable transfer functions Layer three “QoS-aware” routing/packet forwarding and label-based forwarding, traffic engineering, protection/ restoration User Applications “QoS-based” applications (IP voice/video, Internet gaming, etc.), and traditional “besteffort” applications (web browsing, ftp, telnet, etc.) TCP/UDP (Transport) IP-MPLS (Network/Data) Hardware (electronic packet buffering/processing and even optical switching) Physical Layer Slide 24 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 25 Emerging Architectures: MPLS MPLS Label-Switching Node Constant inter-packet timing, fixed packet size Time IP MPLS Router Voice distortion dependant upon MPLS resource control (e.g., per-flow or per-class) Voice packet streams Variable inter-packet timing, variable packet sizes Time Time Data packet streams Label encapsulation, label swapping Time Time Generic resource control engine (buffering, scheduling) Fixed link speed Label encapsulated user packets/datagrams (i.e., MPLS “shim” header) MPLS packet mapping (via forward equivalent class, FEC), packet encapsulation with MPLS header Slide 26 Emerging Architectures: MPLS MPLS Network Label In Link Out 1 23 3 21 2 15 5 27 … … … … 5 3 1 89 MPLS Router A Label control Label Out Resource control MPLS Router B Resource control Label processing operations (edge mapping, swapping, stacking): arbitrary granularity and resource control Label-switched paths (incoming labels overwritten with outgoing labels after switching, based upon label table entries) MPLS Router D Label control Link In Label control Label Table Resource control User connection flow (e.g., TCP/IP or UDP session) Label control MPLS Router C Resource control Slide 27 Emerging Architectures: MPLS • 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 Slide 28 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 Slide 29