Route My World!

Multicast Sessions

• Several ways for multicast applications to learn about the available sessions or streams:
  • The application may join a predefined group where another multicast application sends announcements about available sessions.
  • The application may contact an appropriate directory service.
  • Clicking on a webpage URL of the sessions.
  • Email announcement of the session.
• Another option is to use an application called Session Directory (sd) that acts like a TV guide with multicast content.
  • A client application runs on a PC and lets the user know of available contents.
  • To learn about the content, this directory application uses either the:
    • Session Description Protocol (SDP) or,
    • Session Announcement Protocol (SAP)
  • The Session Directory application and the Session Description Protocol are sometimes called SDR or sdr.
    • In Cisco documentation SDP/SAP is referred to as sdr.
• The Session Description Protocol tool (or SDR tool) is an application that allows:
  • Session description and its announcements.
  • Transport of session announcement via multicast group 224.2.127.254.
  • Creation of new sessions.
• On the receiver side, SDR allows receivers to see available groups/sessions. To join the session, click on the link.
• On the sender side, SDR allows new sessions to be created and avoid address conflicts
• RFC 3266, Support for IPv6 in Session Description Protocol (SDP), defines the standard set of variables that describe the sessions.
  • This RFC is obsoleted by RFC 4566, SDP: Session Description Protocol.
  • Most of the variables that defines SDP were inherited from the SDR tool.
  • The transport itself is not defined in the RFC. The packets describing the session may be trasported via the following mechanisms:
    • SAP, defined in RFC 2974, Session Announcement Protocol, carries the session information.
    • Session Initiation Protocol (SIP), defined in RFC 3261, SIP: Session Initiation Protocol, is a signaling protocol for Internet conferencing, telephony, instant messaging.
    • RFC 2326, Real Time Streaming Protocol (RTSP), control protocol for multimedia sessions. Allows controls such as forward, rewind, pause, play, and also carries session information.

IGMP

• IGMP is used to register hosts to the router when joining and leaving multicast groups.
• This registration process allows the router to be aware of what host to forward data streams destined to a specific multicast group.
• Hosts identify group memberships by sending IGMP messages to their local multicast router.
• Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet.

IGMP is used between hosts and their local router.

IGMP Version 1

• Defined in RFC 1112, Host Extensions for IP Multicasting.
• Two types of messages:
  • Membership Query
  • Membership Report
• Multicast routers periodically send membership queries (every 60 to 120 seconds) to multicast address  224.0.0.1 (all-hosts).
• Hosts send memebership reports to the multicast address they want to join. Hosts either send reports if they want to join or to respond to membership queries.
• To minimize bandwidth and processing overhead, only one member per group, on each subnet, responds to a query. This process is called report suppression.
• For a multicast traffic to be forwarded to a segment, there has to be at least one active member present.
• IGMPv1 lacks the mechanism for hosts leaving the group.
  • Hosts can leave a group silently, at any time, without notifying the router.
  • Even when there is no longer any host in the group, the multicast session will continue to forward traffic until several query intervals find no response. This leads to inefficiency.

IGMPv1 Message Format

IGMP Version 2

• Defined in RFC 2236, Internet Group Management Protocol, Version 2.
• Due its predecessor’s  limitations, IGMPv2 came to be. Most of the changes between version 1 and version 2 deal with the issues of leave and join inefficiencies.

The following are some important changes in IGMPv2:

• Group-specific queries
  • Allows a router to query membership only in a single group instead of in all groups. This provides an efficient way to find out if any members are left in a group without asking all groups for a report.
  • Membership query vs. group-specific query:
    • Membership query sends multicast to all host address 224.0.0.1
    • Group-specific query for a group “G” is multicast to the group “G” multicast address.
• Leave Group message
  • Mechanism for hosts to notify the router that they are leaving the group.
  • This specification includes the timing of when Leave Group messages must be sent.
• Querier election mechanism
  • The router with the highest IP address on the same segment becones the designated querier.
• Query-interval response time
  • Indicates to the members how much time they have to respond to a query by issuing a report.
  • Controls the “burstiness” of a report

IGMPv2 Message Format

• IGMPv2: Joining a Group
  • When joining a multicast group, members do not have to wait for a query to join. They simply send an report indicating that they want to join.
  • This reduces the latency for a host joining if no other members are present.
• IGMPv2: Leaving a Group
  • When a host leaves a group, it announces its intention to leave by sending a Leave group message to  multicast 224.0.0.2 – all multicast routers.
  • When the router receives the Leave Group message, it sends a group-specific query to check if there is any other members left in the group.
    • If another member is still present, it sends back a report and the router continues to send multicast traffic to the group.
    • If there is no longer any member present, no membership report comes back to the router. The group subsequently times out.
    • It takes approximately from 1 to 3 seconds from the time that the Leave Group message is sent until the group-specific query times out and multicast traffic stops flowing for that group.

IGMP Version 3

• Defined in RFC 3376, Internet Group Management Protocol, Version 3.
• It is proposed standard that adds the ability to filter multicasts based on multicast source so that hosts can indicate that they want to receive traffic only from particular sources within a multicast group.
• This helps in making the utilization of routing resources more efficient.
• IGMPv3: Joining a Group
  • Upon joining a group, the joining member sends a report to 224.0.0.22.
  • This report might specify a source list, which is used for source filtering.
    • A source list is a list of multicast sources that the host will accept packets from or a list of multicast sources that the host will not accept packets from.
  • A source list help avoid delivering multicast packets from specific sources to networks where there are not interested receivers.
• IGMPv3: Operation
  • The router sends periodic queries to the members of the group while all IGMPv3 members respond with reports that contain multiple group state records.

The show ip igmp interface command helps determine what verison of IGMP is running.

Multicast in Layer 2

• Because IGMP is a Layer 3 (Network Layer) protocol, switches are not able to participate in IGMP and are not aware of which hosts attached to them might be part of a particular multicast group.
  • This can be a problem especially when most hosts don’t attach directly to routers, instead they are connected to a Layer 2 switch, which in turn connect to routers.
  • Additionally, mulitcast traffic is forwarded to all ports of a VLAN even if only one device on one port requires the actual multicast stream.
• To go around the problem, Cisco Catalyst switches implements a mechanism where mulitcast MAC addresses can be manually associated with various ports on the switch.
  • This solution is not very scalable because IP multicast hosts dynamically join and leave groups.

CGMP

• Cisco Group Management Protocol (CGMP) is a Cisco Systems proprietary protocol.
• The protocol runs between a router and a switch.
• The routers inform each of their directly connected switches of IGMP registrations that were received from hosts through the switch. The switch then forwards the multicast traffic only to ports that those requesting hosts are on rather than flooding the data to all ports.
• CGMP is based on a client/server model where the router may be considered a CGMP server, and the switch a client.
• CGMP Operation:
  • When the router sees an IGMP control message, it creates a CGMP packet that contains:
    • the request type (join or leave)
    • the Layer 2 multicast MAC address
    • and the actual MAC address of the client
  • The packet is sent to the well-known CGMP multicast MAC address 0×0100.0cdd.dddd, to which all CGMP switches listen.
  • The switch interprets the CGMP control message and creates the proper entries in its MAC address table (also called its forwarding table or content-addressable memory [CAM] table) to constrain the forwarding of multicast traffic for this group to only the appropriate ports.

IGMP Snooping

• With IGMP Snooping, the switch eavesdrop on the IGMP messages sent between the routers and hosts, and updates its MAC address table accordingly.
• The switch is required to be IGMP aware in order to listen to IGMP messages.
• The switch intercepts all IGMP packets that go through it from host to router and vice versa.
• Using IGMP snooping can have considerable increase in performance for the switch because of the fact that it has to examine every Layer 2multicast packets that pass through it in order to identify the IGMP packets.
  • To avoid serious degradation in performance, a Layer 3 switch is better option.

Resources:

1. RFC 4566, SDP: Session Description Protocol
2. RFC 2974, Session Announcement Protocol
3. RFC 3261, SIP: Session Initiation Protocol
4. RFC 2326, Real Time Streaming Protocol (RTSP)
5. RFC 1112, Host Extensions for IP Multicasting
6. RFC 2236, Internet Group Management Protocol, Version 2
7. RFC 3376, Internet Group Management Protocol, Version 3

This entry is not an authoritative guide. These are merely notes and rehash of the primary text materials and resources that I use. For a thorough guide of the BSCI course, consider purchasing Building Scalable Cisco Internetworks (BSCI) (Authorized Self-Study Guide) (3rd Edition) by Diane Teare and Catherine Paquet; Routing TCP/IP, Volume 1 (2nd Edition) (CCIE Professional Development) by Jeff Doyle and Jennifer Carroll; as well as following the links on the resources section of this entry.