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