In Like a Lamb, Out Like a Lion

After a slow start in September, the IESG got busy and issued quite a few RFCs, along with a number of protocol and document action announcements.

 By Pete Loshin
Page 1 of 2
Print Article

IETF Corner

The first half of September may have been pretty slow in terms of IESG actions, but the last half saw publication of quite a few new RFCs, as well as quite a flurry of protocol and document action announcements.

The new crop is a very mixed bag, with topics as diverse as MPLS VPNs, DNS security issues, three different multicast topics, a new Internet Standard SMTP extension, phone numbers and DNS, several MIME RFCs, and yes, yet another IPv6 Informational.

Perhaps more notable was the publication of RFC 2799, "Request for Comments Summary RFC Numbers 2700-2799." Every hundred RFCs this type of summary document is released, containing brief descriptions of the previous 99 RFCs in the series. Though RFC 2798 was published half a year ago, the summary RFCs are held back until all the RFC numbers in the series are released--the hold-up was publication of RFC 2700, just this past August. Though notable, RFC 2799 is of relatively little significance, because it is an Informational--and because it doesn't really describe any protocol.

New RFCs

Table 1 lists the new RFCs announced between September 18 and October 1. There were quite a few new ones in the past two weeks--18 in all, which is quite a few when compared to the meager crop from the first half of the month. In addition, the IESG announced approval of 20 new documents as RFCs (see Table 2).

Table 1: RFCs Announced September 18 through October 1, 2000

A Multiplicity of Multicast Documents

The trio of multicast RFCs released, 2907 through 2909, covers a range of issues with various RFC types: RFC 2907, "MADCAP Multicast Scope Nesting State Option," is a Proposed Standard; RFC 2908, "The Internet Multicast Address Allocation Architecture," is an Informational; and RFC 2909, "The Multicast Address-Set Claim (MASC) Protocol," is an Experimental.

It's best to start with the Informational in this triplet, "The Internet Multicast Address Allocation Architecture." RFC 2908 describes a proposed architecture for handling the way multicast addresses are allocated with the Internet. The approach taken is similar to that taken by the Dynamic Host Configuration Protocol (DHCP) to allocate unicast addresses (although it is not similar enough to share any significant protocol specifications).

RFC 2908 divides the architecture into three layers; it starts with Layer 1, at which individual clients are able to request multicast addresses from multicast address allocation servers (MAASs). At Layer 2, the MAASs coordinate with each other and with "Prefix Coordinators" within their own domains (intra-domain) to make sure that the MAASs have unique ranges of multicast addresses to allocate to their clients. Finally, at Layer 3, Prefix Coordinators can coordinate the allocation of multicast addresses across domains (inter-domain).

Going next to the Proposed Standard, RFC 2907, "MADCAP Multicast Scope Nesting State Option," we see an example of a modification to one of the leading mechanisms for allocating multicast addresses at Layer 1. Multicast Address Dynamic Client Allocation Protocol (MADCAP) defines such a mechanism; RFC 2907 defines an option by which MADCAP clients can "learn not only which scopes exist via the existing 'Multicast Scope List' option," but "also how these scopes nest inside each other." As a result, clients can "make better scope selections for a given session" and can also "construct hierarchies of administratively scoped zones." With those hierarchies, the clients can "perform expanding scope searches instead of the expanding ring or increasing-TTL searches."

Finally, the Experimental RFC 2909: "The Multicast Address-Set Claim (MASC) Protocol." MASC defines a mechanism for exchanging information about multicast address allocations across domains--at Layer 3 of the architecture described in RFC 2908.

This article was originally published on Oct 15, 2000
Get the Latest Scoop with Networking Update Newsletter