IP-Multicasting Technology Part 3:
Protocol Timing, Sizing and Decoding

1.0 IP-Multicast: Timing and Sizing the Protocols

The various IP-Multicast protocols offer different levels of throughput and reliability. For effective IP multicasting, the timing and sizing requirements for the IP Multicasting protocols must be considered. The different timing values for each protocol are a key part of differentiating the performance requirements for your IP-Multicast applications. Values such as timer and timeout values, as well as table structure and sizing, are used to accurately calculate the timing and sizing requirements for each protocol. While the decision criteria for the selection of a particular protocol is more complex than a simple tradeoff of speed versus reliability, no single multicast protocol meets the needs of all multicast requirements.

As discussed in previous articles, the most popular IP-Multicast protocol for an enterprise is clearly PIM-SM (Protocol Independent Multicasting - Sparse Mode), with DVMRP (Distance Vector Multicast Routing Protocol) a distant second. The Mbone (Multicast Backbone) still uses a great deal of DVMRP; however, the Mbone is primarily a core Internet infrastructure and not one that most enterprises deal with internally. PIM-DM (Protocol Independent Multicasting - Dense Mode) would be third statistically, with MOSPF (Multicast Open Shortest Path First) being utilized the least. An exterior Internet routing protocol, BGPv4, has recently been extended to provide for inter-AS multicast routing and has been designated "MBGP" (Multicast BGP).

In polling a representative set of enterprises, research suggests that the minimum required IP-Multicast group active population, e.g. (S,G) count in DVMRP and (*,G) count in PIM-SM, is approximately 256, with the typical population being closer to 2,000 for many organizations. The maximum observed in the subset polled was close to 10,000 active groups on a corporate network. Military and defense contractors would most likely have requirements for an even higher active group count.

Ascertaining the total maximum active multicast groups supported for a given vendor's router/switch product line is not a simple task since many protocols, unicast and multicast, must share available RAM and CAM space. Clearly, though, the high-end Cisco and Nortel Networks routers can easily manage tens of thousands of simultaneous multicast groups. This fact is another reason that MOSPF (described in previous articles) is not highly favored as the IP-Multicast protocol of choice for large installations, since the operating overhead required to maintain the unicast and multicast topologies becomes increasingly excessive.

The data below details timing information for various IP Multicasting protocols:

2.0 IP-Multicast: Decoding the Protocols

Our final area of discussion is decoding the various protocols. This section provides a relatively complete decode analysis of the Ethernet Frame Format (Layer-2, Data Link Header), PIM-SM, PIM-DM, and IGMP (the leave/join protocol common to all IP-Multicast routing protocols). While this data may not be relevant from an application perspective, it is valuable for debugging purposes.

(Note: All values in this section that begin with the prefix "0x" are hexadecimal values. Values without the "0x" prefix are decimal.)

2.1 Ethernet Decodes (Layer-2, Data Link Header)

There are four types of Ethernet (CSMA/CD) frame types:

• V2 (Version 2.0) (the original "Ethernet" frame type)
• 802.2/LLC
• 802.3/SNAP
• Novell Raw

To ascertain which of the Ethernet types is present in a given frame, developers may use the decode logic presented in this section.

2.1.1 Address Fields Are Common To All Ethernet Formats

Octets 0 - 5: The MAC Destination Address (48-bit, 6-octets)

  if field = '0xFFFFFFFFFFFF',
    then frame is a MAC broadcast

  if field's LSB of first octet is '1' and the address is not broadcast,
    then frame is a MAC multicast

  else the frame is a MAC unicast

Octets 6 - 11: The MAC Source Address (48-bit, 6-octets)

All MAC Source addresses must be unicast (e.g. from one source)

2.1.2 Decode Length/Type Field

Octets 12 - 13: The Length or Type Field (16-bit, 2-octets)

  if field <= 0x5DC

    then field is a "Length" and frame is a either an 802.2/LLC, 802.2/SNAP, or Novell Raw frame. The length is the total octets contained in Layers 3 thru 7 payload and does not include the Layer-2 CRC (4 bytes) at the end of the frame. -> goto 2.1.3;

  else field is a "Type" and frame is a V2 (Version 2.0) frame. The type is really a protocol number that specifies what Layer-3 protocol header will be found immediately following the type. Another name for the type in a V2 frame is "EtherType". The EtherTypes are maintained by the IANA standards organization and are well-known values. -> goto 2.1.5;

2.1.3 Decode 802.2/LLC, 802.3/SNAP and Novell Raw Frame Types 

Octets 14 - 15: DSAP/SSAP or Novell Field (16-bit, 2-octets)

  if field = 0xFFFF
    then frame is a Novell "Raw". The 0xFFFF is followed by an IPX Layer-3 routing header, i.e. this frame is for use only by the Novell IPX/SPX protocol stack. It cannot hold TCP/IP data. ->goto Novell Processing;

  if field = 0xAAAA
    then frame is 802.3/SNAP. Protocol information is follows. -> goto 2.1.4;

    else frame is 802.2/LLC (Logical Link Control). The field's first octet is called the Destination Service Access Point (DSAP), while the field's second octet is called the Source Service Access Point (SSAP). These two values refer to the protocol type of the upcoming Layer-3 header. In addition, a 1 octet (8-bit) Control Byte follows the DSAP and SSAP fields (Octet 16). The value of the Control is set to 0x03 on Ethernet segments. -> goto 2.1.5;

2.1.4 Decode 802.3/SNAP Frame Type 

Octets 16 - 21: Control Byte, OUI, and Type fields

The 802.3/SNAP frame has a 0xAAAA value for the DSAP/SSAP field and a 0x03 value for its Control Byte (Octet 16). Following the control byte, the OUI (Organizationally Unique Identifier) field is found (Octets: 17 thru 19). The OUI specifies which vendor's protocol stack will be used, e.g. Digital's DECnet, IBM's SNA, DoD's TCP/IP, Apple's AppleTalk, and so forth. The last two octets at 20 and 21 are the Protocol Type, specify which protocol will be used in the Layer-3 header of the frame. -> goto 2.1.5;

2.1.5 Layer-3 and Subsequent Layer Headers and Application Payload 

The remaining data represents a series of protocol headers (also called Protocol Data Units or PDUs), starting with the Network Layer (Layer-3) and followed by Layers 4 through 7 (L4 = Transport, L5=Session, L6=Presentation, L7=Application). A header for each layer may not be present, depending on the protocol stack and the general characteristics of the frame. For example, the TCP/IP protocol stack does not use any Layer5 or Layer6 protocol headers, while the OSI protocol stack may use all of them.

The end of the frame is delineated by a CRC (Cyclic Redundancy Check), sometimes called a FCS (Frame Check Sequence). This 32-bit, 4-octet field is used to validate the integrity of the Ethernet frame upon reception. If the receiving node does not calculate the same CRC for the frame that the sender did, the frame is rejected as damaged.

2.2 IGMP Decode - Version 2

IGMP (Internet Group Management Protocol) is designed to allow end nodes and any immediately neighboring IP-multicast enabled routers (and Layer-3 switches) to converse about which users are interested in which multicast source traffic (i.e. "join" and "leave" operations). IGMP is used by routers and Layer-3 switches as a companion to the IP-Multicast routing protocol of choice, be it DVMRP, PIM-SM, PIM-DM, MOSPF, or other protocol. The IGMP protocol is an integral part of IP, as is the case with ICMP (Internet Control Management Protocol). IGMP's IP "protocol type" is of value two (2). The IGMP messages, encapsulated in IP datagrams, have a TTL (Time To Live) field value of one (1). In this way, the IGMP messages never move beyond the local Ethernet segment. In addition, the messages contain the IP Router Alert Option in their IP header. (Please reference RFC 2113 for more details on this IP header option.)

The logic for decoding of the IGMP protocol (using the Version 2 timing as defined above) is as follows:

2.2.1 Layer-2/3 Decode for IGMP

  if ( Layer-2 Data Link header "protocol type" field = 0x0800 and Layer-3 IP header "protocol type" field = 0x02 )
    then the packet is a IGMP message packet.

2.2.2 IGMP Message Decode

The 64-bit (8-octet) IGMP Message is broken into these four (4) fields:

Bits	0 - 7	Type
Bits	8 - 15	Maximum Response Time
Bits	16 - 31	Checksum
Bits	32 - 63	Group Address (IP-Multicast Source Address)

"Type Field"

The IGMP "type" field can take on the following values:

0x11 = "Membership Query"
0x16 = "Membership Report, V2"
0x17 = "Leave Group"

with one additional type used for backwards compatibility with Version 1:

0x12 = Membership Report, V1"

Two subtypes of the Membership Query message are possible - the "General Query" used to learn which groups have members on an attached network, and the "Group-Specific Query" used to learn if a particular group has any members on an attached network. The Group Address field is used to differentiate the two subtypes (see below).

Special Note: A value of three (0x03) for the type provides the DVMRP routing protocol the ability to distribute source tree information between routers. (See below)

"Maximum Response Time" Field

The Maximum Response Time field is meaningful only in Membership Query messages and specifies the maximum allowed time (in units of 1/10 second) before sending a responding report. In all other messages, the field is set to zero (0) by the sender and ignored by receivers.

Varying this field's setting allows an IGMPv2 router to tune the "leave latency" - the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members). This field also allows tuning of the "burstiness" of IGMP traffic on a given subnet.

"Checksum" Field

The checksum field is the 16-bit one's complement of the one's complement sum of the whole IGMP message, i.e. the entire IP payload. For computing the checksum, the checksum field is first set to zero. When transmitting packets, the checksum must be computed and inserted into this field. When receiving packets, the checksum must be verified before processing a packet.

"Group Address" Field

The Group Address field is the "meat" of the IGMP message. In a Membership Query message, the group address field is set to zero (0) when sending a General Query and set to the group address being queried when sending a Group-Specific Query. In a Membership Report or Leave Group message, the group address field holds the IP multicast group address of the group being reported or left.

Other IGMP Fields

Please note that IGMP messages may be longer than eight (8) octets, especially future backwards compatible versions of IGMP. As long as the "type" is recognized, an IGMPv2 implementation must ignore anything past the first eight (8) octets while processing the packet. However, the IGMP checksum is always computed over the whole IP payload, not just over the first eight (8) octets.

2.2.3 Using the Decode to Implement IGMP-Snooping

By using the IGMP Layer 2/3 decode of 2.2.1, one may implement the "IGMP Snooping" technique described in Part 2. IGMP Snooping, if you recall, referred to the ability of a switch to be able to decode a multicast packet to determine if it was a control packet (IGMP) or an actual data-bearing packet. Thus, repeating the logic for section 2.2.1:

  if ( Layer-2 DLH "MAC destination address" field is Multicast and
    Layer-2 DLH "protocol type" field = 0x0800 and
        Layer-3 IP header "protocol type" field = 0x02 )
    then the packet is a IGMP message packet
  else the packet contains normal IP-Multicast dataNote:

The "IP protocol type" has a fixed location relative to the start of the Layer-3 IP header. It is the 10th octet (byte) in the Layer-3 IP header. This protocol value specifies what type of header follows the IP header.

2.3 PIM-SM/DM Decodes - Version 2

The Protocol Independent Multicast protocol (both for Sparse Mode and Dense Mode) uses control messages that have a IP header "protocol" field value of 103. PIM messages use either IP unicast addresses (e.g. the "Registers" and "Register-Stop" messages) or IP multicast addresses with the ALL-PIM-ROUTERS group value ("224.0.0.13") (e.g. the "Join/Prune" and "Asserts" messages).

Each of the nine PIM control messages is pre-pended with a "PIM Message Header" described in section 2.3.2 below.

The following logic may be used for decoding the PIM protocol:

2.3.1 Layer-2/3 Decode for PIM

  if ( Layer-2 Data Link header "protocol type" field = 0x0800 and
    Layer-3 IP header "protocol type" field = 0x67 )
  then the packet is a PIM message packet.

2.3.2 PIM Message Header Decode

The 32-bit (4-octet) PIM Message Header is broken into four (4) fields:

Bits  0 -  3: PIM Version
Bits  4 -  7: Type
Bits  8 - 15: Reserved
Bits 16 - 31: Checksum

"PIM Version" Field

The current version of PIM (SM and DM) is two (2).

"Type" Field

The PIM Message Header "type" field can take on the following values: (DR="Designated Router", RP="Rendezvous Point", MC="Multicast Traffic", BSR="Bootstrap Router", IR="Intermediate Router", DMO=Dense Mode Only)

0x00 = "Hello" // sent periodically on all router interfaces
0x01 = "Register" // sent by DR to the RP for MC traffic
0x02 = "Register-Stop" // sent by DR to the RP to stop MC traffic
0x03 = "Join/Prune" // sent by routers to upstream sources & RPs 0x04 = "Bootstrap" // originated at the BSR and sent to IRs
0x05 = "Assert" // used to avoid duplicate paths to receiver
0x06 = "Graft (DMO)" // re-instate a pruned branch
0x07 = "Graft-Ack (DMO)" // response to a "Graft"
0x08 = "Candidate-RP-Advertisement" // sent periodically from each candidate-RP to the BSR

"Reserved" and "Checksum" Fields

The "Reserved" field is ignored by receivers and is always set to zero (0) by senders. The "Checksum" field is the 16-bit one's complement of the one's complement sum of the entire PIM message, excluding the data portion in the "Register" message). The "Checksum" field is first zeroed before computing the checksum.

2.3.3 PIM Message Address Formats

Within each PIMv2 message, addresses are encoded in one of three ways - a Unicast Address, a Group (IP-Multicast) Address, and a Source Address. Each has its own 32-bit or 64-bit format within a PIMv2 message.

Unicast Address Encoding

Bits  0 - 7:  Address Family
Bits  8 - 15: Encoding Type
Bits 16 - 15: Unicast Address

Address Family is one of the following IANA-assigned values:

0x00 = "Reserved"
0x01 = "IPv4" // ** most common setting **
0x02 = "IPv6"
0x03 = "NSAP"
0x04 = "HDLC (8-bit multi-drop)"
0x05 = "BBN 1822"
0x06 = "802 - includes all 802 media plus Ethernet canonical format"
0x07 = "E.163"
0x08 = "E.164 (SMDS, Frame Relay, ATM)"
0x09 = "F.69 (Telex)"
0x0A = "X.121 (X.25, Frame Relay)" 0x0B = "IPX"
0x0C = "Appletalk"
0x0D = "Decnet IV"
0x0E = "Banyan Vines"
0x0F = "E.164 with NSAP format sub-address"

Encoding Type is always set to zero (0)

Unicast Address as represented by the given Address Family and Encoding Type

Group Address Encoding

Bits  0 -  7: Address Family
Bits  8 - 15: Encoding Type
Bits 16 - 23: Reserved
Bits 24 - 31: Mask Len
Bits 32 - 63: Group Multicast Address

Address Family is as described above.

Encoding Type is as described above.

Reserved is transmitted as zero (0). Ignored upon receipt.

Mask Len is set to 32 for IPv4 native encoding and 128 for IPv6 native Encoding.

Group Multicast Address contains the group address.

Source Address Encoding

Bits  0 -  7: Address Family field
Bits  8 - 15: Encoding Type field
Bits 16 - 20: Reserved field
Bits 21 - 23: S, WC, RPT field
Bits 24 - 31: Mask Len field
Bits 32 - 63: Source Address field

Address Family is as described above.

Encoding Type is as described above.

Reserved is transmitted as zero (0). Ignored upon receipt.

S, WC, RPT is a set of three bits with the following special meanings:

"S-bit": the Sparse bit is set to one (1) for PIM-SM and is used for PIM Version 1 compatibility only.

"WC-bit": the WC bit is set to one (1) if the join or prune applies to the (*,G) or (*,*,RP) entry. It is set to zero (0) if the join or prune applies to the (S,G) entry where S is Source Address. Joins and prunes sent toward the RP must have this bit set."

RPT-bit": the RPT is set to one (1,) if the information about (S,G) is sent towards the RP. If set to zero (0), the information must be sent toward S, where S is the Source Address.

Mask Len is set to 32 for IPv4 native encoding and 128 for IPv6 native Encoding.

Source Address is the address sourcing the multicast traffic.

Of all the PIM message types mentioned above, the most important message type for keeping an IP-Multicast CAM table up-to-date is the "Join/Prune" message - type 0x03.

A Join/Prune PIM message utilizes the following format:

Bits  0 -  3: PIM Version field
Bits  4 -  7: Type field
Bits  8 - 15: Reserved field
Bits 16 - 31: Checksum field
Bits 32 - 63: Upstream Neighbor Address field (Encoded-Unicast)
Bits 64 - 71: Reserved field
Bits 72 - 79: Num Groups field
Bits 80 - 95: Holdtime field
Bits 96 and beyond: a series of Multicast Group Blocks
----- end of Join/Prune message -----

Each Multicast Group Block contains:

Bits  0 - 31: Group Address #1 field (Encoded-Multicast)
Bits 32 - 47: Number of Joined Sources field
Bits 48 - 63: Number of Pruned Sources field
Bits 64 and beyond: a series of Joined Source Addresses, and then a series of Pruned Source Addresses

Each Joined Source Address is 32-bits and is Encoded-Source. Each Pruned Source Address is also 32-bits and is Encoded-Source

The first four fields of the Join/Prune message comprise the PIM message header (described in 2.3.2 above). The type field is set to 0x03 for the Join/Prune type.

The Upstream Neighbor Address is the IP unicast address of the RPF or upstream neighbor. This is the router that is being targeted with the Join/Prune message. The Reserved field is transmitted as zero and ignored upon receipt.

The Num Groups field specifies the number of Multicast Group Blocks that follow the Holdtime field. Each MGB specifies a series of Join and Prune source addresses for a given IP-Multicast group.

The Holdtime field specifies the amount of time a receiver must keep the Join/Prune state alive, in seconds. If this field is set to 0xFFFF, the receiver of this message never times out (useful for ISDN lines). If this field is set to zero (0), the information is timed out immediately.

Within the MGB, we start with the Group Address field which specifies the IP-Multicast group that will have a series of joins and prunes, which is followed by the Number of Joined Sources and Number of Pruned Sources fields that specify the number of each. The Joined Source Addresses are then listed, followed by the Pruned Source Addresses.

The Control Plane must use these Join/Prune messages to add and remove entries to the IP-Multicast CAM, referred to as the Multicast Forwarding Table (MFT)

Conclusion

Over the past few years, organizations have dramatically increased their use of the Internet to communicate and collaborate. Many have revised their business practices in order to take advantage of the Internet as a facilitator of communication. Over the next several years, this trend should continue with IP Multicasting becoming an increasingly important technology for delivering information to large, geographically disparate audiences.

Great strides in refining and improving IP Multicasting have been made and continue to be made today. This set of articles should provide developers with a basic understanding of this enabling technology as they begin to implement IP Multicasting in their own companies or organizations.