Multimedia Applications and Internet Architecture

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