Token Ring Multicast Addressing

Token Ring Multicast Addressing

The bit order of the transmitted bytes for token ring is the opposite of ethernet. For example, the token ring address C0:00:00:05:00:01 has the binary representation

1100 0000 0000 0000 0000 0000 0000 0101 0000 0000 0000 0001

When written in ethernet form, the order of the bits in each byte is reversed, so the ethernet binary representation would be

0000 0011 0000 0000 0000 0000 1010 0000 0000 0000 1000 0000

which has the hexadecimal form

03:00:00:A0:00:80.

The mapping of a multicast Class D IP address for token ring can be accomplished using one of two methods. The first method is to map all Class D multicast IP addresses to a single token ring functional address as shown:

224.x.x.x-> C0:00:00:04:00:00

The general form of a token ring functional address is C0:00:00:04:xx:xx. Functional addresses are used for token ring functions, such as Ring Error Monitor. The last two bytes usually have only one bit set to 1 and a bit in the third byte is used to determine if this address is a functional address. The third byte of an ethernet multicast address is 5E, which, if used in a token ring to multicast IP address mapping, would trick the token ring hosts into accepting that the multicast address is functional. This is the reason that the same mapping method used for ethernet cannot be used for token ring. Mapping all IP multicast addresses to the same token ring functional address means that token ring end stations cannot determine if the multicast traffic is destined for them until the packet is examined at layer three. If multicast traffic is present on the token ring, then every host must examine the packet at layer three (in software), instead of at layer two (by the network interface card). This can put a strain on end stations that are not listening for packets of that particular multicast group.

The other method of mapping multicast IP addresses to token ring addresses is to simply map every multicast IP address to the broadcast address:

224.x.x.x -> FF:FF:FF:FF:FF:FF

To force the token ring interface to use the functional address, use the following command in interface configuration mode:

interface Token-ring 0

ip multicast use-functional

Internet Group Management Protocol, IGMP Version 1

IGMP is used by hosts to inform the directly connected router of their choice to join a multicast group. IGMP messages have the format shown in Figure 3-5. IGMP messages are encapsulated in IP datagrams and use a protocol identifier of 2.

Figure 3-5: IGMP version 1 message format

Version Number = 1

Type

1 = Host Membership Query 2 = Host Membership Report

Unused

Set to zero when sending Ignore when receiving

Checksum

16-bit complement of the complement sum of the 8-byte IGMP message

Group Address

Host Membership Query Message = 0 Host Membership Report Message = IP multicast address of the group being reported

A router sends Host Membership Query messages to determine if any hosts are members of any multicast groups (see Figure 3-6). As long as one host responds to the query, then the router must continue to send multicast traffic for that group to the network. Queries are sent to the all-hosts group address (224.0.0.1) and have a TTL value of 1.

Figure 3-6: Multicast routers use IGMP Host Membership Query messages to determine if any hosts are members of any multicast group.

When a host receives a Host Membership Query message, the host responds with one or more Host Membership Report messages (see Figure 3-7). Each Host Membership Report message contains the multicast group of which the host is a member.

Figure 3-7: Hosts report their group memberships with IGMP Host Membership Reports.

If multiple group members are on the network, a flood of report messages can be generated. Two techniques can be employed to avoid this possibility. The first is to have the host start a delay timer with a delay value randomly chosen between zero and some maximum value, usually 10 seconds. When the delay timer expires, the host sends the report. This spreads the Host Membership Reports over time. Because a router only needs to know if there is at least one group member on the network, it is not necessary for every host that is a member of a group to send a Host Membership Report message.

The second technique is to send the report to the host group address that is being reported. Hosts still use the delay timer, but if they receive a Host Membership Report for the group that they are waiting to report, the timer is canceled and no report is sent. This method is preferred because only one report is generated for each Host Membership Query (see Figures 3-8 and 3-9).

Figure 3-8: Routers determine group membership using IGMP Host Membership Queries.

Figure 3-9: Host report group memberships with IGMP Host Membership Reports.

In Figure 3-8, when hosts A, C, and D receive a Host Membership Query message from the router, the hosts start a timer with a random value. When the first timer counts down to zero, an IGMP Host Membership Report is sent, as in the example by host A. When host A sends the report, the timer values for hosts C and D have decremented by one. Before the timers for host C and D expire, they receive the Host Membership Report that is sent by host A. Because this is a report for the group that they are waiting to report to, there is no need for hosts C and D to send their reports.

The various states that a host can be in are shown in Figure 3-10. Hosts can be in one of three states: Non-Member, Delaying Member, and Idle Member. In the Non-Member state, a host is simply not a member of the multicast group. The Delaying Member state indicates that the host is a member of the multicast group, has received a Host Membership Query message from the router, and has the report delay timer running. A host enters the idle state after it has sent a Host Membership Report message to the router or has heard a Host Membership Report from another host that is a member of the group. Hosts will make transition between states on the occurrence of the following events:

Figure 3-10: IGMP Version 1 host state diagram

1.   A host decides to join a multicast group.

2.   A host decides to leave a multicast group.

3.   A Host Membership Query message is received.

4.   A Host Membership Report is received.

5.   The host’s delay timer has expired.

When a host decides to join a multicast group, it does not know if any other hosts are on the network that are members of the group. If this host is the first member and the host waits for a Host Membership Query from the router, the host will wait forever. Therefore, when a host decides to join a multicast group, it should immediately send a Host Membership Report.

The possibility exists, however, that this initial report message will not reach the router. The host should make a transition from the Non-Member state to the Delaying Member state, as though the host had received a Host Membership Query message. The host then starts the delay timer. If a Host Membership Report is received, the host stops the timer and makes a transition to the Idle Member state. If the timer expires, the host sends a Host Membership Report message to the router and then moves to the idle state. When a Host Membership query is received, the host could be in any of the three states. In the Non-Member state, the host simply ignores the message. In the idle state, the host will make a transition to the delaying state and start the report delay timer. If the report is received while the host is in the delaying state, the host does not reset the timer but continues to delay with the current timer value. Finally, when a host decides to leave the group, it does so silently because there is not a leave group message in IGMP version 1. If the host is the last host to leave the group, the router does not know this until there has been no response to the router’s periodic Host Membership Query messages.

Internet Group Management Protocol, IGMP Version 2

IGMP version 2 is detailed in RFC 2236 (Copyright © The Internet Society 1997), written by W. Fenner of Xerox PARC in November 1997. IGMP version 2 messages have the format shown in Figure 3-11. The shaded parameters highlight the changes from the IGMP version 1 packet.

Figure 3-11: IGMP version 2 packet format

Type:

0x11 = Membership Query

0x16 = Version 2 Membership Report

0x17 = Leave Group

0x12 = Version 1 Membership Report for backwards              compatibility with IGMP version 1.

Membership Query messages, type 0x11, come in two flavors. The first is a General Query that is used to determine which groups on a network have active members. The second is a Group-Specific Query that is used to determine if a particular multicast group has active members. The type of Membership Query message can be determined by the group address. For a General Query, the group address is zero and, for a Membership Query, the group address contains the address of the multicast group that is being queried.

The Maximum Response Time field (Max. Rtime) applies only to Membership Query messages. This field specifies the maximum amount of time a host can wait before responding to a Membership Query report. Maximum Response Time is in units of 0.1 seconds.