Multimedia%20Applications%20and%20Internet%20Architecture

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_at_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
  ltFlow Label, Source Address, Destination Addressgt
  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 ltFlow Label, Source
  Address, Destination Addressgt 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 -gt
  expand , or encrypt -gt 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
  ltRoleIDgtltNodeIDgt pairs.
• A wildcard can replace ltNodeIDgt if RSH can be
  processed by any instance of RoleID that it
  encounters on its path.
• Ex. ltRole AddrgtltRoleIDgt_at_ltNodeIDgt ltRoleIDgt_at_
• Ex. RSH( HBHforward_at_ dest-NodeID, src-NodeID
  ),
• / Forwarding role instance in every
  router /
• RSH( Deliver_at_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 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.

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 senders provider chain
  and then flows down along receivers 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 ltsource address, destination
  addressgt
• 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

51
Thank you
52
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/mp
  ls/
• 5 http//www.sm.luth.se/avri/index/smd076/NG-In
  ternet-Arch-Braden.pdf
• 6 Xiaowai Yang, "NIRA A New Internet Routing
  Architecture". ACM SIGCOMM FDNA 2003 Workshop,
  Karlsruhe, August 2003