* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Multimedia Applications and Internet Architecture
Survey
Document related concepts
Net neutrality wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Internet protocol suite wikipedia , lookup
Net neutrality law wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Deep packet inspection wikipedia , lookup
Quality of service wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Transcript
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 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 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 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 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 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 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 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 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 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 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 IPv6 Protocol Header 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. 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 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 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 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 IPv6 Flow Label Values Pseudo Random Number Approach Direct Parametric Representation 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 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 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. 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). Labels Labels are contained in the label stack. 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 MPLS Operation Figure Example of two streams of data packets entering an MPLS domain 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 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 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 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. RBA - Introduction (Contd.) In keeping with the “end to end” argument, we have the layered Internet architecture. RBA – Introduction (Contd) Layered Architecture provides: Modularity. Packet header format and header processing rules. 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… RBA - Idea Non Layered Architecture? Stack Heap 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. 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} RBA - Example RBA – Packet Layout Example 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 */ } RBA – What can we expect? Clarity - Replace “layer violations” with architected role interactions. Freedom of choice on functional granularity – can re-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. RBA – What do we lose? Requires replacement of deployed protocols. Less Efficient - More overhead in header space and processing. 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. 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 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 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 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 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. 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 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 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 Thank you References [1] RFC 2460 Internet Protocol, Version 6 (IPv6) [2] Bhanu Prakash, Using the 20 bit Flow Label Field in the IPv6 header to indicate desirable Quality of Service on the Internet. MS thesis, University of Colorado 2004. [3] Braden, R., Faber, T., Handley, M., "From Protocol Stack to Protocol Heap -- Role- Based Architecture". HotNets-I, Princeton, NJ, October 2002. [4] The International Engineering Consortium (IEC), “Multiprotocol Label Switching (MPLS),” Sept. 2000; http://www.iec.org/online/tutorials/mpls/ [5] http://www.sm.luth.se/~avri/index/smd076/NG-Internet-Arch-Braden.pdf [6] Xiaowai Yang, "NIRA: A New Internet Routing Architecture". ACM SIGCOMM FDNA 2003 Workshop, Karlsruhe, August 2003