Border Gateway Multicast Protocol (BGMP)

Multicast protocols need AS border router attention too. This section deals with the Border Gateway Multicast Protocol, or BGMP. BGMP comes with the capability of building multicast group trees in the style of PIM-SM, where only group members belong to the tree at any given time. However, these trees don’t consist of individual routers. Instead, each tree has only BGMP border routers as members. Once this tree is built, some domains build their own internal trees from there, depending on the protocol they are using.

The multicast domain advertising the availability of a specific range of multicast channels is considered the root for that range. Remember that multicast channels each consist of a single class D Internet address, which range from 224.0.0.0 through 239.255.255.255. So, perhaps our AS has the range of multicast channels from 231.15.19.120 through 231.15.19.140. BGMP would consider our AS the root domain for that range.

When a user joins a multicast group outside their domain or AS, their request is passed to the BGMP router.This router looks up the address for the router handling the root domain containing this particular channel. Once the BGMP router knows which domain to send the request to, it generates a BGMP UPDATE message containing the following information:

• Address prefix. This prefix tells BGMP the length of the included netmask.

• Address family, protocol family, or protocol suite—these all refer to the same thing. The type of networking protocol collection that this packet was meant to travel on. For the purposes of this discussion, let’s assume that you’re using an Internet-like network, and on it you’re using TCP/IP.

• Address. The multicast address this UPDATE message refers to.

• Netmask. The netmask associated with the multicast address included in this UPDATE message.

• JOIN message declaration. This parameter specifies that this UPDATE message is in fact a JOIN message.

• Additional declarations. A BGMP UPDATE message can carry multiple message types. In this case the primary attribute is JOIN. So, this message also could serve the function of GROUP, SOURCE, or POISON_REVERSE. Inside these, you could nest even more JOINs, PRUNES, and so on.

The BGMP router now looks in its tables and sends this UPDATE message to the router that will take it one step closer to the multicast root domain. The receiving router looks to see whether it already has an entry that tells it to forward data for this multicast group to the requesting router. If it doesn’t, it creates this entry and sends the packet to the next closest BGMP router. This router looks to see whether it’s already forwarding data from this group to the requesting domain. If not, it creates an entry to do so and continues. This process follows along the tree from router to router until the UPDATE message reaches the root domain.

Eventually, users leave.When a user disconnects from a multicast channel that is broadcast from outside its domain, the BGMP router is notified. This router first looks to see whether it has any other group members within its domain. If not, it generates an UPDATE message that is different from the JOIN message in one simple fact: Rather than having a bit set to tell the UPDATE it’s carrying JOIN information, there’s a bit set telling it that this UPDATE message carries PRUNE information.

The UPDATE message is sent along using the same pattern as a JOIN UPDATE message would use. It’s sent hop by hop along the shortest path to the root domain. Each router along the way sees if it is serving any other members of this multicast group. If it is, the UPDATE message stops, and there is no need to send it along. However, if this was the only destination requesting data from that group, the UPDATE message advances further down the tree.

Along with changing multicast group memberships, BGMP routers also have to deal with changes in the overall multicast routing tables. Over time channels are added and removed as transmission content is retired and new players emerge.

BGMP is in many ways related to BGP but, as you can see, has features that allow it to work well in conjunction with multicast transmissions. The programs under Linux that implement this protocol are zebra and the multicast version of gated.