1 / 54

Networking Futures

Networking Futures. As more and more devices (workstations, servers, routers) are connected to the Internet, the network address space needs to scale. This is being addressed by the IPv6 protocol.

lihua
Download Presentation

Networking Futures

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. Networking Futures • As more and more devices (workstations, servers, routers) are connected to the Internet, the network address space needs to scale. This is being addressed by the IPv6 protocol. • More devices, together with emerging multimedia applications, imply that the network bandwidth needs to scale. This is being addressed by going from shared to switched media networks and evolving network standards such as gigabit ethernet, OC-12, OC-48 and OC-192 ATM and HIPPI-6400.

  2. Network Futures • Emerging multimedia, visualization and teleimmersion applications require guaranteed quality of service (QoS) end to end. This is being addressed by the RSVP (Resource Reservation Protocol) protocol. • Multimedia applications require support for effective multicast.

  3. IPv6 • IP requires that device addresses be unique • IPv4 supports 32 bit addresses which limits the address space. • To solve the IP address space depletion for the foreseeable future, IPv6 will expand the address field from 32 to 128 bits.

  4. IPv6 Hierarchical Routing • Besides a larger (and therefore scalable) address space, scalable routing is also needed to maintain the viability of the Internet. • It is believed that hierarchical routing currently used in IPv4 is scalable enough to sustain the growth of the internet with the larger address space.

  5. IPv6 Hierarchical Routing (Cont.) • Hierarchical routing requires that the address assignment reflects the network topology. Consequently, as the network topology changes, address may need to be changed. • The adoption of hierarchical routing to scale the Internet routing system requires simple, low cost renumbering technology.

  6. IPv6 Hierarchical Routing (Cont.) Ex. If you change your Internet Service Provider, you will need to change addresses of all your hosts and routers. unm.edu UNM Domain Electrical Engineering Domain Computer Science Domain eece.unm.edu cs.unm.edu tularosa.eece.unm.edu Host within the eece.unm.edu domain

  7. IPv6 Address Autoconfiguration • The primary function of IPv6 address autoconfiguration is to enable an IPv6 host to configure its IPv6 address automatically without human intervention to enable the transition from IPv4 as seamlessly as possible.

  8. IPv6 Address Autoconfiguration (Cont.) • While currently defined IPv6 host renumbering attempts to minimize the disruption of applications during address renumbering, it does not guarantee totally non-disruptive behavior. To guarantee non non disruptive behavior would require changes to transport layer protocols such as TCP and UDP. This was not done.

  9. IPv6 Address Autoconfiguration (Cont.) • Supporting IPv6 will have less impact on routers than on hosts since host applications may include specific IP addresses. • IPv6 is still being developed so users of TCP/IP technologies should carefully analyze their networking requirements and IPv6 product availability (and robustness) and use this information to decide when and how to transition to IPv6. • For more details, seehttp://www.cisco.com/wrap/public/732/ipv6_wp.html

  10. Non Real Time Non Real Time Real Time Asynchronous Interactive Interactive Broadcast Time-Insensitive Transmission Multicast Multicast n to m cast 1 to m cast Constant rate, low jitter Bulk Transmission Bursty Transmission Data Acquisition, Telemetry Multimedia Applications involving voice, video Telnet FTP E-mail Usually use Leased lines Emerging Applications set Current distributed computing using the Internet Application Groups .

  11. Application Groups (Cont.) • Data acquisition and telemetry are examples of real-time data collection that usually use dedicated (or leased) lines to prevent data loss. Ex. Transmission of image information from the observatories on top of mt. Haleakala to the MHPCC. • Current distributed computing applications such as telnet (remote login), FTP, E-mail etc use the Internet and services that are provided on a “best effort basis”. If the network is congested, the response times and transmission rates are slow.

  12. Multimedia Application Groups • Emerging multimedia applications are near real time and require both high bandwidth and Quality of Service guarantees. Examples are given below: ApplicationStored Data streamsNear real time Data streams ( Asynchronous) (Interactive) - Point to point Multimedia mail with Audio and Video (1 to 1) audio and video clips telephony - Broadcast Stored LAN TV, Interactive distance (1 to m) Corporate Training education Live TV broadcast - General mul- Audio and video -ticast (n to m) conferencing

  13. Multimedia Application Groups (Cont.) • In general, today’s voice, video and data networks are separate but in the future they will change to a common infrastructure. • Voice and video are another manifestation of data and, when digitized, they can be stored, retrieved and processed (edited) and disseminated (transmitted) using computers and data networks.

  14. Multimedia Bandwidth Requirements • For voice, bandwidth of 64Kbps is quite adequate but the jitter (variation in delay) must be small. • For video, the bandwidths required are much greater. • 80 - 400Mbps without compression. • 1.5 - 7 Mbps with compression. Per video stream

  15. Multimedia Bandwidth Requirements (Cont.) • Bandwidth requirements without compression for moving pictures. EGA, VGA, SVGA are standards for computer displays. NTSC and PAL are standards for TV’s in the US and Europe respectively. FormatPixels/ Lines/ Bits/ Frames/ Mbps FrameFramePixelSecond EGA 640 350 6 60 80.6 VGA 640 480 6 60 110.6 SVGA 800 600 8 72 276.5 NTSC 600 485 24 30 209.5 PAL 580 575 24 50 400.2

  16. Multimedia Bandwidth Requirements (Cont.) • Compression/ decompression dramatically reduces the bandwidth requirements. • MPEG2 can compress video by a factor of 30 - 100 to 1. With MPEG2 compression, the following bandwidths are required for various quality levels. MPEG2 Quality LevelBandwidth required VHS VCR player quality 1.5 Mbps Broadcast quality 5.0 Mbps Studio quality 7.0 Mbps

  17. Still image bandwidth requirements

  18. Multimedia Bandwidth Requirements (Cont.) • The bandwidth requirements for various applications can therefore be summarized as follows: • ApplicationDesktop Connectivity • Conventional distributed Shared Enet hubs. Upto 100 users • computing per Enet. • Client / Server Shared Enet hubs. Upto 50 users • per Enet. • Voice and video Shared Enet hubs. Upto 10 users • conferencing per Enet. • Video on demand, imaging Dedicated Enet / user i.e. 10Mbps • switched Enet is mandatory. • Virtual reality, teleimmersion 100Mbps / user i.e. 100Mbps switched Enet,ATM, switched FDDI.

  19. Multimedia Bandwidth Requirements (Cont.) • Bandwidth hierarchies for Ethernet: • Shared 10Mbps to • Switched 10Mbps or shared 100Mbps to • Switched 100Mbps to • Switched 1000Mbps. • Bandwidth hierarchies for ATM • OC-1 (optical carrier level 1) is 51.84 Mbps to • OC-3 i.e. 155.52Mbps to • OC-12 i.e. 622Mbps to • OC-48 i.e. 2.488Gbps to • OC-192 i.e. 9.953Gbps (still evolving).

  20. Multimedia Bandwidth Requirements (Cont.) • Bandwidth hierarchies for FDDI: • 100 Mbps shared to • 100 Mbps switched to • 1000 Mbps shared to • 1000 Mbps shared. However, since ethernet chip set are made in high volumes, they drive the costs down making ethernet much more cost effective than FDDI. Many of the above FDDI products may, therefore, not be developed since ethernet may be more cost effective.

  21. Multimedia Bandwidth Requirements (Cont.) • Bandwidth hierarchies for Token ring: • 4 Mbps shared to • 4 Mbps switched • 16 Mbps shared to • 16 Mbps switched • Higher speeds (being discussed).

  22. Multimedia Bandwidth Requirements (Cont.) • Bandwidth hierarchies for HIPPI (High Performance Parallel Interface): • 800 Mbps (parallel) HIPPI to • 800 Mbps serial HIPPI to • 800 Mbps switched HIPPI to • 1600 Mbps switched HIPPI to • 6400 Mbps switched HIPPI HIPPI is a specialized high performance LAN technology that is used primarily in high performance computer LAN environments.

  23. Maximum Throughputs • The following table gives estimates for the maximum throughput of various technologies using the TCP/IP protocol. The numbers may vary depending on the operating system used.

  24. Maximum Throughputs

  25. Multipoint Packet Delivery • Many multimedia applications are most effective when they involve multiple participants. An example is video conferencing among m users. • These applications can be “bandwidth hogs” if not effectively implemented and can cause severe network congestion. • Their effective implementation is very important. Several research groups and organizations are working on this problem.

  26. Multipoint Packet Delivery (Cont.) • There are 3 ways to implement multipoint communications: • Unicast. Send m copies of the data. One copy to each of the m recipients. This is very wasteful of bandwidth and has terrible scaling properties. • Broadcast. Send the data as a broadcast packet to all portions of the network to ensure that it reaches all the intended destinations. This is also very wasteful of bandwidth and has poor scaling properties.

  27. Multipoint Packet Delivery (Cont.) • Multicast. Send the data as a multicast packet that is addressed only to the intended recipients. The network replicates the packet where necessary. • Multicast is very efficient. It is easy on the hosts and the networks. • For multicast to work, the network devices need to know the destinations and be able to dynamically build efficient paths and forward the packet to all destinations.

  28. Multipoint Packet Delivery (Cont.) • IP multicast has been used to build the MBONE, an experimental multicast backbone running on top of the commodity Internet. • The MBONE is used for collaborative research by scientists and engineers who need a rich communication infrastructure.

  29. Network Service Levels • Interactive multimedia applications, such as video conferencing cannot be effectively provided on a “best effort basis”. They require guaranteed • Bandwidths • Constant delay (i.e. low jitter) • Synchronization between the video and voice streams. • Other applications may require other guaranteed service levels.

  30. User User Application Application Host Host Service Request Network Service Level Offering Network Service Levels (Cont.) • Service levels are described by: • Committed information rates (CIRs) or • Classes of service (COS’s) or • Types of services (TOS’s) or • Qualities of services (QoS’s). • These should be specific and measurable.

  31. QoS Parameters • The qualities of service usually requested include application to application: • Bandwidth • Latency or delay • Jitter or variation in delay • Synchronization between multiple streams (eg the voice should be synchronized with the video). • Packet or cell loss ratio (% of packet/cells dropped). • Cell/Packet error ratio (% of packets/cells arriving with one or more errors).

  32. QoS Parameters (Cont.) • Near real time applications are sensitive to the various QoS parameters. They require a constant bit rate of delivery. • Voice conferencing requires 64Kbps of bandwidth, tolerates 200 ms end to end delays and about 100 ms of jitter i.e. a delay of 150 + 50 ms. Bandwidth in excess of 64Kbps is wasted i.e. not used. • People find jitter in excess of 100 ms to be annoying. • Voice conferencing is relatively tolerant of errors and packet/cell loss ratios of better than 1 in 10-4.

  33. QoS Parameters (Cont.) • Video is much more bursty in nature than audio and requires between 256Kbps (eg low quality video conferencing) and 7.0 Mbps for studio quality compressed video. • End to end delays of 200ms can be tolerated. • The tolerance to jitter is similar to that of voice for low quality and about 5ms for studio quality. • Tolerance for errors and packet/cell loss varies with quality desired from 1 in 106 to 1 in 107 or better.

  34. QoS Parameters (Cont.) • To meet these various QoS parameters, applications can be divided into three classes depending on the type of traffic they generate, specifically • Constant bit rate (CBR) applications. • Variable bit rate (VBR) applications. • Available bit rate (ABR) applications.

  35. High Utility Low Bandwidth Constant Bit Rate Applications • Audio traffic and old video codecs (coder/decoder) inject a constant bit rate traffic into networks. • These applications cannot function with less bandwidth than some minimum application specific requirement. • They do not benefit from extra bandwidth. • In circuit-switched network, they receive a dedicated bandwidth.

  36. High Utility Low Bandwidth Variable Bit Rate Applications • LAN TV, modern video codecs (i.e. using MPEG2) produce a variable bit rate traffic in networks. • The stream is bursty. Sometimes the bandwidth required is low and sometimes it is high. • When the VBR traffic is below the peak rate, the extra bandwidth is not used. • Packet/cell switched networks are designed to provide the average bandwidth, while peaks are handled by statistical sharing of extra bandwidth.

  37. High Utility Low Bandwidth Available Bit Rate Applications • Traditional computer applications and emerging multimedia e-mail applications can function over a wide range of available bandwidths. • They require little bandwidth to run slowly and run faster when more bandwidth is available. • Current data networks provide excellent support for ABR applications with the “best-effort” quality of service.

  38. ATM QoS • Native end to end ATM supports control over the bit rate (bandwidth), latency, jitter and cell loss. QoS featureCBRVBRABR Latency Specifiable Specifiable Specifiable Jitter Specifiable Specifiable Not Specifiable Cell loss Specifiable Specifiable Not Specifiable

  39. TCP solutions for QoS • ATM was built to integrate voice, video and data. • Pure ATM networks therefore support QoS features. • RSVP (Resource Reservation Protocol) is being developed to provide QoS for IP networks.

  40. RSVP • RSVP is a protocol designed to reserve network resources for important applications as a way to achieve near real-time Internet services. • Since bandwidth reservation on a given route is a zero sum game, resources reserved for one application cause other applications to loose bandwidth and therefore run more poorly.

  41. RSVP (Cont.) • RSVP is being incorporated into products of all major router vendors, which should spur software makers to develop applications that will take advantage of RSVP. • RSVP is a resource reservation and not a routing protocol, so RSVP must use the local routing protocol to obtain routes.

  42. RSVP (Cont.) • When an application requests a specific quality for its data stream, the host computer system uses RSVP to deliver (cascade) the request to all routers on the stream’s path, all the way to the destination, and maintain the router and host state that is necessary to provide the service. • When all routers and the destination agree to honor the request (by squeezing other “best effort” i.e. ABR streams), the application can proceed.

  43. RSVP (Cont.) • When all routers and the destination cannot honor the request, because not enough resources are available to satisfy the request, a request denied signal is sent to the application, which then may suspend itself and try again later.

  44. Limitations of RSVP • RSVP is nice in theory but it will be interesting how it evolves in practice. • The RSVP technology can be implemented and is relatively simple compared to the anticipated administrative, managerial and practical problems that are expected to be encountered with its use.

  45. Limitations of RSVP (Cont.) • Some of these problems include : • Who determines what user can have what quality of service privileges over what routes ? • How will that user be authenticated ? • How will coordination of RSVP data streams be resolved when different entities control different parts of the network ? • Perhaps the biggest obstacle to the broader deployment of RSVP (or similar) services is the financial issue of settlement.

  46. Limitations of RSVP (Cont.) • Network service providers will want to be reimbursed for the additional costs incurred in providing quality of service for data transmission crossing their backbones. • Consequently, it is quite likely that organizations will implement quality of service applications (eg audio and video conferencing) on their internal networks first because of the uncertainty that they can be provided satisfactorily over networks controlled and shared by others.

  47. Limitations of RSVP (Cont.) • The future of quality of service applications from anywhere will depend on the willingness of user’s to pay for it and the ability of providers to develop a well-defined business model for marketing, billing and selling the service.

  48. What The Future Holds • Computers will continue to be smaller, cheaper, faster and more reliable. • Storage will continue to be smaller, cheaper and more reliable, but not much faster (when compared to CPU speed increases). • Software will continue to be more useful and easier to use but it will consume increasing amounts of memory and CPU.

  49. What The Future Holds (Cont.) • Data communication will continue to be faster, more reliable and cheaper in terms of cost per byte transmitted. • While the cost of computing (including storage and communication) per unit of work will decrease, the number of units of computing used will increase much faster than the cost will decrease. • The net result is that the total cost of computing will increase.

  50. What The Future Holds (Cont.) • Computing and networking will be increasingly seen as an investment rather than as an expense as organizations learn to better measure the return on the investment for computing and networking. • To survive, organizations will be investing where the return on the investment is greatest.

More Related