1 / 52

Multimedia Applications and Internet Architecture

Multimedia Applications and Internet Architecture. Nawab Ali, Muthu Manikandan Baskaran, Ryan Bogadi, Aakash S Dalwani and Prachi Gupta Department of Computer Science and Engineering The Ohio State University Columbus, OH 43210 {alin, baskaran, bogadi, dalwani, guptapr}@cse.ohio-state.edu.

axelle
Download Presentation

Multimedia Applications and Internet Architecture

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. Multimedia Applications and Internet Architecture Nawab Ali, Muthu Manikandan Baskaran, Ryan Bogadi, Aakash S Dalwani and Prachi Gupta Department of Computer Science and Engineering The Ohio State University Columbus, OH 43210 {alin, baskaran, bogadi, dalwani, guptapr}@cse.ohio-state.edu

  2. Presentation Outline • Introduction • Internet Architecture • Multimedia Applications and Requirements • Multimedia and the Current Internet • Multimedia Capable Internet • Internet Protocol version 6 (IPv6) • IPv6 Flow Labels • Multiprotocol Label Switching (MPLS) • Role Based Architecture (RBA) • New Internet Routing Architecture (NIRA) • Conclusion • References

  3. Internet Architecture • Importance • Architecture guides technical development such as protocol design in a consistent direction • Short-term solutions “without architectural thinking” leads over time to a design that is complex, tangled and inflexible • Challenges to current Internet Architecture • High traffic volume in the Internet • Emerging application requirements such as QoS for multimedia traffic

  4. Multimedia Application Requirements • Different kinds of media have different characteristics • Real time media – audio/video • High network throughput • Loss tolerant • Delay sensitive • Low latency • Low delay variation • Non real time media – web data • Less delay sensitive • Reliable transmission

  5. Presentation Outline • Introduction • Internet Architecture • Multimedia Applications and Requirements • Multimedia and the Current Internet • Multimedia Capable Internet • Internet Protocol version 6 (IPv6) • IPv6 Flow Labels • Multiprotocol Label Switching (MPLS) • Role Based Architecture (RBA) • New Internet Routing Architecture (NIRA) • Conclusion • References

  6. Multimedia and the Current Internet • Current Internet not suitable for Multimedia • Infrastructure and protocols designed for reliability • Best-effort service • No QoS guarantees - Network conditions such as bandwidth, packet-loss ratio, delay, and delay jitter vary from time to time. • Multimedia applications have strict service requirements • Explicit delay bounds • Limits on packet loss rates • Egalitarian nature • All packets are treated as equal • Differentiated classes of service does not exist

  7. Existing Multimedia Support • Provide abundant network bandwidth • Despite high-bandwidth networks, network congestion still present • No guarantees that the Internet will be free of bottleneck links • Resource reservation • Integrated Services • RSVP • Differentiated Services • Multimedia Transmission Protocols • RTP • RTCP

  8. Network Requirements for Multimedia • Broadband network architecture • Native flow control • Dynamic resource allocation and deallocation • Connection oriented fast circuit-switching • Transport service • Multi-rate channels, Short setup time, Fixed switching delay

  9. Multimedia and Internet Architecture • New Architecture Design and Features • Role based Architecture • New Internet Routing Architecture • Integrated service (IntServ) & Differentiated service (DiffServ) • Label switching • IPv6 • Web caches

  10. Presentation Outline • Introduction • Internet Architecture • Multimedia Applications and Requirements • Multimedia and the Current Internet • Multimedia Capable Internet • Internet Protocol version 6 (IPv6) • IPv6 Flow Labels • Multiprotocol Label Switching (MPLS) • Role Based Architecture (RBA) • New Internet Routing Architecture (NIRA) • Conclusion • References

  11. Internet Protocol Version 6 • IPv6 [RFC 2460] is the latest version of the Internet protocol • Provides support for Multicast, Anycast • Major changes from IPv4 • IP address size increased from 32 bits to 128 bits • Header format simplification • Flow Labeling Capability

  12. IPv6 Protocol Header

  13. Flow Support in IPv6 • A FLOW [1] is a sequence of related packets sent from a source to a unicast, anycast, or multicast destination • Flow labeling with the Flow Label field enables classification of packets belonging to a specific flow • Flow Label is used for providing QoS in IPv6.

  14. Flow Support in IPv6 [2] • Flow state is established in a subset or all of the IP nodes on the path • Includes the Flow classifier • Defines the Flow-specific treatment the packets should receive • Can be signaled, or configured by a control protocol. • IPv6 routers classify packets based on the Flow label value

  15. Flow Label Specification • A packet is classified to a certain flow by the <Flow Label, Source Address, Destination Address> triplet • Allows the same Flow Label value to be used with different destinations • The Flow Label value is meaningless out of the context of the addresses • Non-zero Flow Label value for labeled flows, no other requirements

  16. Flow Label Specification (cont.) • The IPv6 node assigning a Flow Label value MUST keep track of all the <Flow Label, Source Address, Destination Address> triplets in use • To prevent mixing separate flows together • The Flow Label value MUST be delivered unchanged to the destination • IPv6 nodes not providing flow-specific treatment MUST ignore the field when receiving or forwarding a packet

  17. IPv6 Flow Label Values • Various IETF proposals have tried to define the 20 bits in the Flow label field [2] • Represent QoS parameters • No QoS Requirements

  18. IPv6 Flow Label Values • Pseudo Random Number Approach • Direct Parametric Representation

  19. Presentation Outline • Introduction • Internet Architecture • Multimedia Applications and Requirements • Multimedia and the Current Internet • Multimedia Capable Internet • Internet Protocol version 6 (IPv6) • IPv6 Flow Labels • Multiprotocol Label Switching (MPLS) • Role Based Architecture (RBA) • New Internet Routing Architecture (NIRA) • Conclusion • References

  20. Multiprotocol Label Switching (MPLS) • MPLS [4] is an IETF-specified framework • It provides a means for supporting QoS and CoS for service differentiation by: • Grouping data streams with different requirements into different groups called FECs • Use of traffic-engineered path setup and thereby achieve service level guarantees. • Allowing constraint-based and explicit path setup

  21. MPLS Building blocks • Label-Switched Path (LSP) • Sequence of labels at each node along the path. • Based on criteria in the forwarding equivalence class. • Routing Devices • Label Edge Router (LER) • At the edge of the access and MPLS networks. • Forwards network traffic using the label signalling protocol. • Label Switching Router (LSR) • Establishes the label switched path. • Label Distribution Protocol (LDP) • Protocol for distribution of label binding information to LSRs • Used to map FECs to labels, creating LSPs.

  22. Forward Equivalence Class (FEC) • A group of packets having the same requirements • Packets in same FEC will have the same MPLS label & get the same treatment • FECs are based on service requirements for a given set of packets or for an address prefix • Each LSR builds a table to specify how the packet must be forwarded. This table is called the Label Information Base (LIB).

  23. Labels • Labels are contained in the label stack.

  24. MPLS Operation • Label creation and distribution • Routers bind a label to a specific FEC and build their tables & create LSPs using LDP • In LDP, downstream routers initiate label distribution and the label/FEC binding. • Table creation (at each router) • Each LSR creates entries in the label information base (LIB). • Entries are updated whenever label bindings are renegotiated • Label-switched path creation • Label insertion/tablelookup • The first router uses the LIB table to find the next hop and request a label for the specific FEC. • Subsequent routers just use the label to find the next hop. • At egress LSR, the label is removed and the packet is supplied to the destination. • Packet forwarding • Packet is forwarded along the LSP

  25. MPLS Operation Figure

  26. Example of two streams of data packets entering an MPLS domain

  27. MPLS & multimedia • MPLS supports QoS and CoS for service differentiation by way of: • Traffic Engineered path setup • Enhances network performance through uniform or differentiated traffic distribution. • In MPLS, traffic engineering is inherently provided using explicitly routed paths. • LSPs are created independently, specifying different paths based on user-defined policies • RSVP & CR-LDP supply dynamic traffic engineering and QoS in MPLS

  28. Constraint-based routing (CR) • Constraint-based routing (CR) takes into account parameters, such as • Link characteristics like bandwidth & delay, Hop count, QoS • CR-LSPs generated with explicit hops or QoS requirements as constraints • Explicit hops dictate the path to be taken. • QoS requirements dictate which links and queuing or scheduling mechanisms are to be employed. • The IETF has defined a CR-LDP component to facilitate constraint-based routes

  29. Presentation Outline • Introduction • Internet Architecture • Multimedia Applications and Requirements • Multimedia and the Current Internet • Multimedia Capable Internet • Internet Protocol version 6 (IPv6) • IPv6 Flow Labels • Multiprotocol Label Switching (MPLS) • Role Based Architecture (RBA) • New Internet Routing Architecture (NIRA) • Conclusion • References

  30. RBA - Introduction • One of the most respected and cited Internet design principles – “End to End” [3] • The core of the network should provide a general service, not one that is tailored to a specific application. • Innovation - Low barriers for new applications. • Reliability - Lesser points of failures. • Network that is transparent: packets go in, and they come out - and that is all that happens in the network.

  31. RBA - Introduction (Contd.) • In keeping with the “end to end” argument, we have the layered Internet architecture.

  32. RBA – Introduction (Contd) • Layered Architecture provides: • Modularity. • Packet header format and header processing rules.

  33. RBA- Motivation • Traditional layered architecture faces serious challenges in the modern Internet. [4] • Layer violations • Sub-layer proliferations • E.g., MPLS at 2.5, IPsec at 3.5, and TLS at 4.5. • Erosion of “End-to-End” model – middleboxes • Firewalls, NATs, proxies, caches…

  34. RBA - Idea Non Layered Architecture? Heap Stack

  35. RBA – Design • Non Layered Architecture • Modularity • Role: Functional Specification of communication building block. • Packet Header Format • An arbitrary collection (heap) of sub-headers: “role data” • These are called Role-Specific-Headers (RSH): addressed to roles. • New rules for order (not LOFO) and access – RSH divide header information along role boundaries. • Granularity. • Tradeoff – processing overhead Vs reusability.

  36. RBA – Design (Contd) • RSHs can be added, modified, or deleted as a packet is forwarded. • Presence or absence of RSHs may be significant. • Roles communicate with each other only via RSHs. • Roles can be coupled in conjugate pairs like {Encrypt, Decrypt} {Compress, Expand} etc. • Can enforce sequencing rules like {compress -> expand} , or {encrypt -> decrypt}

  37. RBA - Example

  38. RBA – Packet Layout Example

  39. RBA – Addressing and Processing • Each Role is identified by a unique RoleID. • RSHs are addressed to a Role on a Node using <RoleID><NodeID> pairs. • A wildcard can replace <NodeID> if RSH can be processed by “any instance of RoleID that it encounters on its path”. • Ex. <Role Addr>:=<RoleID>@<NodeID> | <RoleID>@* • Ex. { RSH( HBHforward@* ; dest-NodeID, src-NodeID ), /* Forwarding role instance in every router */ RSH( Deliver@dest-NodeID ; serviceID, src-processID, payload), /* Deliver payload to specific service at dest node */ }

  40. RBA – What can we expect? • Clarity- Replace “layer violations” with architected role interactions. • Freedom of choice on functional granularity – canre-modularize large and complex protocol layers into smaller units. • Auditability - Can leave RSHs after they have been “consumed”, to signal to downstream nodes that a function has been performed. • Provides an explicit place for middlebox metadata.

  41. RBA – What do we lose? • Requires replacement of deployed protocols. • Less Efficient - More overhead in header space and processing.

  42. RBA - Conclusion RBA might prove to be the new design principle of the modern Internet or might just be useful as only an abstraction for reasoning about protocols – it has a lot of scope of future research.

  43. Presentation Outline • Introduction • Internet Architecture • Multimedia Applications and Requirements • Multimedia and the Current Internet • Multimedia Capable Internet • Internet Protocol version 6 (IPv6) • IPv6 Flow Labels • Multiprotocol Label Switching (MPLS) • Role Based Architecture (RBA) • New Internet Routing Architecture (NIRA) • Conclusion • References

  44. NIRA – Introduction • New Internet Routing Architecture (NIRA) • An architecture that is designed to give a user the ability to choose domain-level route • Why a New Internet Routing Architecture? • Users have little control over routes • User choice fosters innovation of new services • Stagnation in introducing new services, e.g., lack of end to end QoS • Service provider enters market with new QoS offering • ISPs team up and users choose a sequence of such ISPs and get access to enhanced QoS – suited for multimedia applications

  45. NIRA – Network Model • “Valley-free route” • Packet pushed up along sender’s provider chain and then flows down along receiver’s provider chain • “Core” • Region of the network where packets cannot be further pushed up

  46. NIRA – Addressing and Efficient route representation • Hierarchical provider-rooted addressing • A “valley-free” or canonical route can be represented by <source address, destination address> • Non-canonical routes need more addresses

  47. NIRA – Scalable Route Discovery • Topology Information Propagation Protocol (TIPP) • Propagates to a user his inter-domain addresses and the route segments associated with these addresses, subject to policies • Basic TIPP messages do not include dynamic conditions of interconnections.

  48. NIRA – Route Discovery (cont.) • Name-to-Route Resolution Service (NRRS) • To discover other user's route segments • Hard-coded addresses for bootstrapping • A fundamental trade-off: topology change will cause address change • Root servers reside in top-level providers

  49. NIRA – Route Availability Discovery • A combination of proactive notification and reactive feedback • Advanced TIPP messages include dynamic conditions of interconnections • “Uphill routes” - Proactive notification via TIPP • “Downhill routes” – Reactive discovery via router feedback or timeout

  50. NIRA – Advantages • Scalability • Efficiency • Robustness • Efficient failure handling • Heterogeneous user choices • Users allowed to choose different providers • Practical provider compensation • Providers have control over various network resources • Benefit from giving a user the ability to choose from multiple routes

More Related