Ars-msr 1 Mcast 2013

Embed Size (px)

DESCRIPTION

multicast

Text of Ars-msr 1 Mcast 2013

  • Multicast Communications

    Arhitecturi pentru retele

    si servicii (ARS)

    Managementul serviciilor si retelelor (MSR)

  • Octavian Catrina 2

    Multicast communications

    Multicast communications

    Data delivered to a group of receivers. Typical examples:

    One-to-many (1:N)

    one-way

    MS

    MR

    Many-to-many

    (N : M)

    MS/R

    MS/R

    One-to-many (1:N)

    two-way

    MS

    MR/US

    Chapter outline

    What applications use multicast? What are the requirements

    and design challenges of multicast communications?

    What multicast support does IP provide (network layer)?

    After an overview of multicast applications, we'll focus on IP

    multicast: service model, addressing, group management, and

    routing protocols.

    M=Multicast; U=Unicast

    S= Sender; R=Receiver

  • Octavian Catrina 3

    Multicast applications (examples)

    One-to-many Real-time audio-video distribution:

    lectures, presentations, meetings,

    movies, etc. Internet TV. Time

    sensitive. High bandwidth.

    Push media: news headlines,

    stock quotes, weather updates,

    sports scores. Low bandwidth.

    Limited delay.

    File distribution: Web content

    replication (mirror sites, content

    network), software distribution.

    Bulk transfer. Reliable delivery.

    Announcements: alarms, service

    advertisements, network time, etc.

    Low bandwidth. Short delay.

    Many-to-many Multimedia conferencing: multiple

    synchronized video/audio streams,

    whiteboard, etc. Time sensitive.

    High bandwidth, but typically only

    one sender active at a time.

    Distance learning: presentation

    from lecturer to students, questions

    from students to everybody.

    Synchronized replicated resources,

    e.g., distributed databases. Time

    sensitive.

    Multi-player games: Possibly high

    bandwidth, all senders active in

    parallel. Time sensitive.

    Collaboration, distributed

    simulations, etc.

  • Octavian Catrina 4

    Sender

    Rcvrs

    -

    6 5

    2 1

    4 3

    7

    Multi-unicast

    delivery

    Multicast requirements (1)

    Efficient and scalable delivery

    Multi-unicast repeats each data item.

    Wastes sender and network resources.

    Cannot scale up for many receivers

    and/or large amounts of data.

    Timely and synchronized delivery

    Multi-unicast uses sequential transmission.

    Results in long, variable delay for large

    groups and/or for large amounts of data.

    In particular, critical issue for real-time

    communications (e.g., videoconferencing).

    We need a different delivery paradigm.

  • Octavian Catrina 5

    Multi-unicast vs. Multicast tree

    Multi-unicast delivery 1:N transmission handled as N

    unicast transmissions.

    Inefficient, slow, for N1: multiple

    packet copies per link (up to N).

    Multicast tree delivery Transmission follows the edges of

    a tree, rooted at the sender, and

    reaching all the receivers.

    A single packet copy per link.

    Sender

    Rcvr

    Rcvrs

    5

    3

    4

    2

    1

    -

    4 3 2

    1

    Multicast tree delivery

    Sender

    Rcvr

    Rcvrs

    5

    3

    4

    2

    1

    -

    4 3 2

    1

    Multi-unicast delivery

  • Octavian Catrina 6

    Multicast requirements (2)

    Group management

    Group membership changes dynamically.

    We need join and leave mechanisms (latency may be critical).

    For many applications, a sender must be able to send without

    knowing the group members or having to join (e.g., scalability).

    A receiver might need to select the senders it receives from.

    Multicast group identification

    Applications need special identifiers for multicast groups.

    (Could they use lists of host IP addresses or DNS names?)

    Groups have limited lifetime.

    We need mechanisms for dynamic allocation of unique

    multicast group identifiers (addresses).

  • Octavian Catrina 7

    Multicast requirements (3)

    Session management

    Receivers must learn when a multicast session starts and

    which is the group id (such that they can "tune in").

    We need session description & announcement mechanisms.

    Reliable delivery

    Applications need a certain level of reliable data delivery.

    Some tolerate limited data loss. Others do not tolerate any loss

    (e.g., all data to all group members - hard problem).

    We need mechanisms that can provide the desired reliability.

    Heterogeneous receivers

    Receivers within a group may have very different capabilities

    and network connectivity: processing and memory resources,

    network bandwidth and delay, etc.

    We need special delivery mechanisms.

  • Octavian Catrina 8

    Requirements: Some conclusions

    Multi-unicast delivery is not suitable

    Multi-unicast does not scale up for large groups and/or large

    amounts of data: it becomes either very inefficient, or does not

    fulfill the application requirements.

    We need new mechanisms and protocols,

    specially designed for multicast.

    Specific functional requirements

    Specific multicast functions, which are not needed for unicast:

    group management, heterogeneous receivers.

    General functions, which are also needed for unicast, but

    become much more complex for multicast: addressing, routing,

    reliable delivery, flow & congestion control.

  • Octavian Catrina 9

    Which layers should handle multicast?

    Data link layer

    Efficient delivery within a multi-access network.

    Multicast extensions for LAN and WAN protocols.

    Network layer

    Multicast routing for efficient & timely delivery.

    IP multicast extensions. Multicast routing protocols.

    Transport layer

    End-to-end error control, flow control, and congestion control

    over unreliable IP multicast.

    Multicast transport protocols.

    Application layer multicast

    Overlay network created at application layer using existing

    unicast transport protocols. Easier deployment, less efficient.

    Still an open research topic.

  • Octavian Catrina 10

    IP multicast model (1)

    "Transmission of an IP datagram to a group of hosts"

    Extension of the IP unicast datagram service.

    IP multicast model specification: RFC 1112, 1989.

    Multicast address

    Unique (destination) address for a group of hosts.

    Different datagram delivery semantics A distinct range of

    addresses is reserved in the IP address space.

    Who receives? Explicit receiver join

    IP delivers datagrams with a destination address G only to

    applications that have explicitly notified IP that they are

    members of group G (i.e., requested to join group G).

    Who sends? Any host can send to any group

    Multicast senders need not be members of the groups they

    send to.

  • Octavian Catrina 11

    IP multicast model (2)

    No restrictions for group size and member location

    Groups can be of any size.

    Group members can be located anywhere in an internetwork.

    Dynamic group membership

    Receivers can join and leave a group at will.

    The IP network must adapt the multicast tree accordingly.

    Anonymous groups

    Senders need not know the identity of the receivers.

    Receivers need not know each-other.

    Analogy: A multicast address is like a radio frequency, on which

    anyone can transmit, and anyone can tune in.

    Best-effort datagram delivery

    No guarantees that: (1) all datagrams are delivered (2) to all

    group members (3) in the order they have been transmitted.

  • Octavian Catrina 12

    IP multicast model: brief analysis

    Applications viewpoint

    Simple, convenient service interface. Same send/receive ops

    as for unicast, plus join/leave ops.

    Anybody can send/listen to a group. Security, billing?

    Extension to reliable multicast service? Difficult problem.

    IP network viewpoint

    Scales up well with the group size.

    Single destination address, no need to monitor membership.

    Does not scale up with the number of groups. Conflicts with

    the original IP model (per session state in routers).

    Routers must discover the existence/location of receivers and

    senders. They must maintain dynamic multicast tree state per-

    group and even per-source&group.

    Dynamic multicast address allocation. How to avoid allocation

    conflicts (globally)? Very difficult problem.

  • Octavian Catrina 13

    IPv4 multicast addresses

    IPv4 multicast addresses

    IP multicast in LANs

    Relies on the MAC layer's native multicast.

    Mapping of IP multicast addresses to MAC

    multicast addresses:

    31 28 27 0

    1110 multicast address

    228 addresses

    Class Address range

    D 224.0.0.0 to

    239.255.255.255

    1 1 1 0 28 bits (228 addresses)

    IPv4 multicast address

    Ethernet multicast address

    0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0 23 bits