Find out what's happening in the wide world of networking standards with information on the new Blocks Extensible Exchange Protocol (BEEP) working group, RFC updates, and other working group actions.
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.
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@example.com. Or, you can just check out the list archive at http://lists.invisible.net/pipermail/bxxpwg/.
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
|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
|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.
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 Internet-Standard.com, Pete frequently consults on Internet protocol issues.