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








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








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








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








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.








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

en.pdf

[6] Xiaowai Yang, "NIRA: A New Internet Routing Architecture".

ACM SIGCOMM FDNA 2003 Workshop, Karlsruhe, August 2003

Multimedia Applications and Internet Architecture

Documents

protocol design

network congestion

delay jitter

short setup time

packetloss ratio

ryan bogadi

aakash s dalwani

muthu manikandan baskaran