Beep, beep!

IETF Corner by Pete Loshin

Last week the IESG approved formation of a new IETF working group, the Blocks Extensible Exchange Protocol (BEEP) working group. Named for the Blocks eXtensible eXchange Protocol (BXXP), the BEEP group will work on “a standards-track application protocol framework for connection-oriented, asynchronous request/response interactions” based on the BXXP specifications written by Marshall Rose of SNMP fame.

As the announced description states, “The framework must permit multiplexing of independent request/response streams over a single transport connection, supporting both textual and binary messages.” In other words, it should prove to be a much better platform for Internet applications than HTTP will ever be.

To participate on the BEEP working group, first subscribe to the mailing list by sending an email with the word “subscribe” in the body to [email protected]. Or, you can just check out the list archive at

New RFCs

The flow of RFCs continued this fortnight, with a baker’s dozen of new ones listed in Table 1, including two new Draft Standards.

Table 1: RFCs published June 26-July 9, 2000

RFC Title Status Date
2859 A Time Sliding Window Three Colour Marker Experimental June 2000
2861 TCP Congestion Window Validation Experimental June 2000
2862 RTP Payload Format for Real-Time Pointers Proposed Standard June 2000
2863 The Interfaces Group MIB Draft Standard June 2000
2864 The Inverted Stack Table Extension to the Interfaces Group MIB Proposed Standard June 2000
2873 TCP Processing of the IPv4 Precedence Field Proposed Standard July 2000
2865 Remote Authentication Dial In User Service (RADIUS) Draft Standard June 2000
2866 RADIUS Accounting Informational June 2000
2867 RADIUS Accounting Modifications for Tunnel Protocol Support Informational June 2000
2868 RADIUS Attributes for Tunnel Protocol Support Informational June 2000
2869 RADIUS Extensions Informational June 2000
2871 A Framework for Telephony Routing over IP Informational June 2000
2872 Application and Sub Application Identity Policy Element for Use with RSVP Proposed Standard June 2000

A new version of the RADIUS specification, RFC 2865, “Remote Authentication Dial In User Service (RADIUS),” moves that protocol forward to Draft Standard, replacing RFC 2138. Another four Informational RADIUS RFCs are out as well, specifying RADIUS accounting and tunnel support as well as RADIUS extensions.

The other new Draft Standard, RFC 2863, “The Interfaces Group MIB,” defines an updated MIB for network interfaces to be managed with SNMP. It replaces RFC 2233, “The Interfaces Group MIB using SMIv2.”

RFC 2871, “A Framework for Telephony Routing over IP,” provides a framework for Telephony Routing over IP (also known as TRIP). After defining the problems related to telephony routing exchange, this informational RFC offers an architectural framework for TRIP and fits it into the context of Internet telephony.

Of special interest in this batch of RFCs are two experimentals. RFC 2859, “A Time Sliding Window Three Colour Marker (TSWTCM),” defines a mechanism for marking packets to be treated differently by downstream routers. Intended to be a component of a differentiated services (diffserv) traffic conditioner, the TSWTCM meters a traffic stream and marks packets one of three colors (green, yellow, or red) based on measured throughput.

The other experimental is RFC 2861, “TCP Congestion Window Validation,” which describes a simple change that can be made to TCP’s congestion control algorithms. The RFC authors make the distinction between TCP connections that are application-limited and those that are network-limited. Application-limited connections are those in which the size of the TCP window (amount of data in flight) is limited because the application just doesn’t need to send or receive that much–as with, for example, the telnet application. Network-limited connections are those that send enough data to fill the TCP window, such as Web connections sending dynamically created data or using HTTP 1.1 persistent TCP connections.

The problem RFC 2861 addresses is that an application-limited connection, especially one in which the application is damped or idled for a long time, tends to skew the TCP congestion window data down–the nodes believe that the window is small. The mechanism described here provides a way to make congestion window information more useful.

The other Proposed Standards this time are RFCs 2862 and 2872. RFC 2862, “RTP Payload Format for Real-Time Pointers,” defines a payload format for the Real Time Protocol (RTP) to be used to carry the coordinates of a dynamic pointer used during an online presentation.

RFC 2872, “Application and Sub Application Identity Policy Element for Use with RSVP,” describes how policy elements that provide application information are to be used with RSVP. RSVP uses policy elements to carry information about a user or application, which may be used by RSVP-aware systems to make policy decisions about the flow of traffic.

Document, protocol, and Working Group Actions

The IESG has been busy approving Internet-Drafts the past couple of weeks, with 14 new documents approved to be published as RFCs and one old RFC promoted to full Internet Standard: RFC 2289, “A One-Time Password System.”

Plenty of Internet-Drafts got the thumbs-up from the IESG as well, though they have yet to cycle through the RFC editor. Right on top of the pile are the Internet Printing Protocol (IPP) specifications, to be published as Proposed Standards.

A new Best Current Practices (BCP) is on its way too, as are several new Proposed Standard RFCs (see Table 2). Look for RFCs on IPv6, multicast, MPLS, and more.

Table 2: IESG protocol and document actions, June 26-July 9, 2000

Title Filename Status
Internet Printing Protocol/1.1: Encoding and Transport draft-ietf-ipp-protocol-v11-06.txt Proposed Standard
Internet Printing Protocol/1.1: Model and Semantics draft-ietf-ipp-model-v11-05.txt Proposed Standard
Use of Label Switching on Frame Relay Networks Specification draft-ietf-mpls-fr-06.txt Proposed Standard
MPLS using ATM VC Switching draft-ietf-mpls-atm-04.txt Proposed Standard
Congestion Control Principles draft-floyd-cong-04.txt BCP (Best Current Practices)
Use of the IDEA Encryption Algorithm in CMS draft-ietf-smime-idea-05.txt Informational
LDAP Control Extension for Server Side Sorting of Search Results draft-ietf-ldapext-sorting-03.txt Proposed Standard
The Cisco SRP MAC Layer Protocol draft-tsiang-srp-02.txt Informational
Router Renumbering for IPv6 draft-ietf-ipngwg-router-renum-10.txt Proposed Standard
A One-Time Password System RFC 2289 Standard
Transition Mechanisms for IPv6 Hosts and Routers draft-ietf-ngtrans-mech-06.txt Proposed Standard
Definitions of Managed Objects for Frame Relay Service draft-ietf-frnetmib-frs-mib-12.txt Proposed Standard
Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function draft-ietf-frnetmib-atmiwf-06.txt Proposed Standard
Key and Sequence Number Extensions to GRE draft-dommety-gre-ext-04.txt Proposed Standard
MADCAP Multicast Scope Nesting State Option draft-ietf-malloc-madcap-nest-opt-05.txt Proposed Standard

In working group actions, other than the BEEP working group approval and a handful of new ones for review, the IESG announced that the Remote Authentication Dial-In User Service (radius) working group in the Operations and Management Area of the IETF has concluded–presaged by the flurry of RADIUS RFCs that came just a few days before.

What’s next

There should be plenty of action in the working group and IETF mailing lists as we move closer to the 48th IETF in Pittsburgh starting the end of July. In the meantime, be on the lookout for yet another revision of the update I-D for SMTP from the Detailed Revision/Update of Message Standards (drums) working group. This one has been cooking for a long time, so we may finally have an updated version of RFC 821 if the drums people can hammer things out sometime soon. //

Pete Loshin has been writing about IP networking since 1988, including 20 books about networking, the Internet, and Internet standards. The founder of, Pete frequently consults on Internet protocol issues.

Latest Articles

Follow Us On Social Media

Explore More