Upload
axelle
View
30
Download
1
Tags:
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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
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
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
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).
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 & 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 – 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 – 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
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