1 / 29

Internet-The Next Generation: Developments in Internet Networking Technologies

Internet-The Next Generation: Developments in Internet Networking Technologies. Outline. Background Best-Effort Architecture Emerging Architectures Conclusions References. Background. Origins of today’s Internet US Dept. of Defense DARPA projects (1960-70’s)

roland
Télécharger la présentation

Internet-The Next Generation: Developments in Internet Networking Technologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • Background • Best-Effort Architecture • Emerging Architectures • Conclusions • References

  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.

  4. 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 Inter-domain BGP routing (red) Various router link technologies (SONET/SDH, ATM, FR)

  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)”

  6. Background 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) Relative Traffic Packet data Voice 1997 1998 1999 2000 2001 Time

  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

  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

  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-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

  10. Best-Effort Architecture Traditional IP Network Hierarchy User Applications “Best-effort” services (e.g., web-browsing, ftp, telnet) Transport control, reliable transfer functions TCP/UDP (Transport) Traditional “best-effort” layer three addressing, routing, packet forwarding IP (Network) SONET Ethernet ATM FR Variety of data and link layer technologies (costs, complexity) Hardware (electronic buffering processing or SONET-type opto-electronic switching) SONET SONET Physical Layer

  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

  12. Best-Effort Architecture FIFO Queueing Node (Edge) Constant inter-packet timing, fixed packet size Outgoing (combined) flows: voice timing very distorted Time IP Router Voice packet stream (phone call) Time Variable inter-packet timing, variable packet sizes Fixed router transmission link speed FIFO queue, voice and data packets mix (G/G/1 model) Time Incoming (individual) traffic flows to IP router queue Data packet stream (web transfer)

  13. 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

  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

  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?)

  16. 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 Flow 2 Time Variable inter-packet timing, variable packet sizes Flow 3 Fixed link speed Per-flow bandwidth scheduler gives capacity guarantees (hardware complexity: tracking, processing/computing) Flow 4 Time Per-flow buffering, voice and data packets separated (G/G/n model) Time Data packet streams

  17. 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

  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

  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)

  20. Emerging Architectures: DiffServ Per-Class Queueing Node (Edge) Constant inter-packet timing, fixed packet size Outgoing (combined) flows: moderate voice timing distortion IP DiffServ Router Time Time Class 1 Voice packet streams Time 1 1 1 1 Fixed link speed Variable inter-packet timing, variable packet sizes Class 2 2 2 Per-class bandwidth scheduler (reduced complexity) Time DiffServ classification maps multiple flows to fewer classes (two shown) by “marking” ToS byte in IPv4 header Time Data packet streams

  21. 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

  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

  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)

  24. Emerging Architectures: MPLS IP-MPLS Network Hierarchy “QoS-based” applications (IP voice/video, Internet gaming, etc.), and traditional “best-effort” applications (web browsing, ftp, telnet, etc.) User Applications Transport control, reliable transfer functions TCP/UDP (Transport) Layer three “QoS-aware” routing/packet forwarding and label-based forwarding, traffic engineering, protection/ restoration Hardware (electronic packet buffering/processing and even optical switching) IP-MPLS (Network/Data) Physical Layer

  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)

  26. Emerging Architectures: MPLS MPLS Label-Switching Node Constant inter-packet timing, fixed packet size Voice distortion dependant upon MPLS resource control (e.g., per-flow or per-class) IP MPLS Router Time Time Voice packet streams Time Generic resource control engine (buffering, scheduling) Label encapsulation, label swapping Variable inter-packet timing, variable packet sizes Fixed link speed Time Label encapsulated user packets/datagrams (i.e., MPLS “shim” header) MPLS packet mapping (via forward equivalent class, FEC), packet encapsulation with MPLS header Time Data packet streams

  27. Emerging Architectures: MPLS MPLS Network Label Table Label-switched paths (incoming labels overwritten with outgoing labels after switching, based upon label table entries) MPLS Router B Label control Resource control MPLS Router D MPLS Router A Label processing operations (edge mapping, swapping, stacking): arbitrary granularity and resource control Label control Resource control Label control Resource control MPLS Router C User connection flow (e.g., TCP/IP or UDP session) Label control Resource control

  28. 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

  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

More Related