IESG Action Spotlight

The first month or so of the year saw an extraordinary amount of activity from the The Internet Engineering Steering Group (IESG), which approved the formation of nine new working groups and dissolution of six old ones. This month, things are still busy even if the IESG is not quite operating at the breakneck pace of January and February. Three new working groups have been approved, Site Multihoming in IPv6 (MULTI6), Application Exchange (APEX), and SIP for Instant Messaging and Presence Leveraging (SIMPLE).

Also of interest, a bit of networking protocol has finally passed into Internet history. STD 39, “Specification for the Interconnection of a Host and an IMP” (BBN Report 1822), published in 1981, was finally reclassified from an Internet Standard to an Historic specification.

Three New Working Groups
This month’s new working groups provide an interesting snapshot of a range of networking concerns: multihoming for improved reliability and performance, use of a new application exchange architecture, and the application of an existing protocol (Session Initiation Protocol) to the instant messaging and presence application.

A multihomed site has more than one link to the Internet; those links can be provided by one or more ISPs. Network managers can multihome their sites for several reasons, but two are of particular importance. First, the security of knowing that if one link is brought down for whatever reason, the site will continue to have Internet connectivity. Second, the ability to do load balancing of traffic across multiple links to improve performance.

Right now, multihoming is done by having each ISP connection advertise the route to the site; this means that there are as many different routes to the same site as there are connections. As the number of multihomed sites increases, the difficulty of maintaining a stable routing infrastructure increases as well.

The new Site Multihoming in IPv6 (MULTI6) working group, in the Operations and Management Area of the Inetnet Engineering Task Force, is chartered to define the current state of the art in multihoming with IPv4, and “explore alternative approaches with better scaling properties.” That means looking at”multi-homing solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ).”

Given that IPv6 is still free from legacies that might interfere with a scalable multihoming architecture, MULTI6 will investigate how best to use the special features of IPv6 to facilitate multihoming.

The Application Exchange (APEX) working group, in the IETF Applications Area, is chartered to “specify protocols and data formats that define a relaying mesh service for loosely-coupled Internet applications, along with specifying services to provide access control and rendezvous-by-subscription.”

The APEX focus will be on defining services for instant messaging and online presence applications, with a key goal being “focused on assuring very low latency between posting and delivery.” In other words, making sure that messages get there quickly to enable real-time conversations.

For another approach to instant messaging, the SIP for Instant Messaging and Presence Leveraging (SIMPLE) working group was also chartered in the Applications Area to apply the Session Initiation Protocol (SIP), defined in RFC 2543, to Instant Messaging and Presence (IMP) applications.

Where the focus of the APEX group is on low latency, the focus of the SIMPLE group is on the use of a protocol (SIP) that is widely deployed and supported as well as relatively mature. Both groups will be working on the same basic problem: defining a set of interoperable standards for instant messaging and presence applications. While it is possible that the APEX group’s solution will be a special one for low-latency applications, it is also possible that one or the other approach will eventually be deemed superior. That is the whole point of IETF working groups – to develop options and see which is best.

Table: New Working Groups: February 23 – March 15, 2001

Working Group Abbreviation
Application Exchange APEX
SIP for Instant Messaging and Presence Leveraging SIMPLE
Site Multihoming in IPv6 MULTI6

It’s History
The IESG approved publication of an Internet Draft that states: “During a review of internet standards, it was brought to the attention of the IESG that the ARPANET Host-IMP protocol, was still listed as an Internet Standard, STD 39. Since this protocol has not been in use in the public internet for well over a decade, the IESG proposes to reclassify it to historic.” The rest of the document is fairly standard boilerplate and abstract.

An Interface Message Processor, or IMP, was a device that switched packets for the ARPANET network. An IMP was an early version of an IP router, capable of connecting groups of nodes with other groups of nodes. BBN Report 1822, describing the Host-IMP protocol, is not available online, but according to Douglas E. Comer (in “Internetworking with TCP/IP” volume 1, page 38) the 1822 protocol was a complex protocol that allowed reliable, flow-controlled data delivery across the ARPANET. Though it has not been relevant for many years, it represents an important step in the development of the Internet as we know it.

What’s Next
IETF 50 starts on March 18 in Minneapolis, and the seasonal flood of Internet-Drafts finally ended on March 9. Over 1200 new I-Ds have been submitted since IETF 49, last December.

Pete Loshin, founder of, is the author of 24 books and frequently consults on Internet standards issues.

Latest Articles

Follow Us On Social Media

Explore More