A modest proposal . . . (a la swift).
Keith Sklower <sklower@cs.berkeley.edu> Mon, 05 December 1994 05:12 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15301; 5 Dec 94 0:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15297; 5 Dec 94 0:12 EST
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa04574; 5 Dec 94 0:12 EST
Received: by atlas.xylogics.com id AA13485 (5.65c/UK-2.1-940401); Mon, 5 Dec 1994 00:08:23 -0500
Received: from vangogh.CS.Berkeley.EDU by atlas.xylogics.com with SMTP id AA13680 (5.65c/UK-2.1-940401); Mon, 5 Dec 1994 00:08:10 -0500
Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Alpha.3/8.6.9.Beta0) id VAA17864 for ietf-rip@xylogics.com; Sun, 4 Dec 1994 21:06:40 -0800 (PST)
Date: Sun, 04 Dec 1994 21:06:40 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith Sklower <sklower@cs.berkeley.edu>
Message-Id: <199412050506.VAA17864@vangogh.CS.Berkeley.EDU>
To: ietf-rip@xylogics.com
Subject: A modest proposal . . . (a la swift).
I discussed these ideas with Gary Malking over the phone a while ago, and noted that he didn't mention them in his draft. Unfortunately, being an inverterate proscratinator, as well as having many other things to do, I didn't get around to composing this note until just now. and I'm not on the mailing list (yet) so I won't see any of your reactions, so please cc: me directly. Network Working Group Keith Sklower NOT an INTERNET DRAFT University of California, Berkeley Expires: May 1, 1995 Compressing RIPv6 packets. draft-ietf-sklower-ripopt-0.txt Status of This Memo This document MIGHT BECOME an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories to learn the current status of any Internet Draft. Abstract This document proposes extensions to the proposed RIP for IPv6 draft which would greatly increase the number of routes that could be conveyed in a single RIPv6 packet. This may be desireable to minimize the amount of Kernel Buffering/ Processing requirements for BSD-based systems. 1. Introduction Back in the dark ages of the Computer Science Department at UC Berkeley, in order to minimize costs and increase the flexibility of systems, we used general purpose time sharing systems as routers, and later as computers became cheaper, bought smaller systems specifically to act as routers. Although some vendors are offering dedicated routers at not much more than double the cost of a reasonably loaded PC, small business or impoverished schools may still choose to initially construct their Sklower [Page 1] Draft RIPv6 Option December 1994 networks out of dual-purpose systems. The author acknowledges this is a heretical and unfashionable point of view, but years of experience with tight-wads persuades him that it will always be the case. Based on the experience of systems with half a dozen networking network interfaces, it was a source of problems to have a routing exchange extend over multiple packets. It seems desireable to be able to compress. This paper offers a mechanism to do so. The author believes that this may be a "selling point" for people to use RIPv6 in lieu of other protocols, like OSPF or ISIS. 2. General Method The general idea is to "factor out" information which is repeated from one entry to the next. For something on the order of the berkeley campus, all of the IPv6 addresses are only likely to differ in one byte; why not try to convey just that one byte of difference? Also almost all of the routes used internally here have the same netmask, so why repeat it in every entry? Similarly, one could establish a presumptive metric which would apply to many routes, and only indicate when it changes. This evening, an examination of the RIP information for the campus backbone showed 152 routes, 148 of which share the same netmask and only differ in one byte. 3. Formal Proposal In the proposal for RIPv6 [1], Gary Malkin describes the following packet format: 0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command (1) | Version (1) | unused | +---------------+---------------+-------------------------------+ | Type (1) | Mask Length(1)| TP Class (1) | Metric (1) | +-------------------------------+-------------------------------+ | | ~ IPng Address (16) ~ | | +---------------------------------------------------------------+ We propose new Types of entries as follows. Sklower [Page 2] Draft RIPv6 Option December 1994 3.1. Common Mask Length +---------------+---------------+ | Type = 3 | Mask Length(1)| +---------------+---------------+ When this entry is encountered, the sender of the packet will omit the Mask Length field from all the remaining entries and the receiver will process the packet as if the preceding Mask Length value had been supplied. It is permissible to have multiple "Common Mask Length" operators in single packet. 3.2. Common Metric +---------------+---------------+ | Type = 4 | Metric | +---------------+---------------+ When this entry is encountered, the sender of the packet will omit the Metric field from all the remaining entries and the receiver will process the packet as if the preceding Metric value had been supplied. It is permissible to have multiple "Common Metric" operators in single packet. 3.3. Common TP Class +---------------+---------------+ | Type = 5 | TP Class(1) | +---------------+---------------+ When this entry is encountered, the sender of the packet will omit the TP Class field from all the remaining entries and the receiver will process the packet as if the preceding TP Class value had been supplied. It is permissible to have multiple "Common TP Class" operators in single packet. 3.4. Common Prefix +---------------+---------------+-------------------------------+ | Type = 6 | Prefix Length | .... DATA ...... | +---------------+---------------+-------------------------------+ Sklower [Page 3] Draft RIPv6 Option December 1994 When this entry is encountered, the sender of the packet will omit the leading Prefix Length bytes from all the remaining entries and the receiver will process the packet as if the supplied data were to be inserted before each entry. It is permissible to have multiple "Common Prefix" operators in single packet. 3.5. Omitted Suffix +---------------+---------------+ | Type = 7 | Suffix Length | +---------------+---------------+ When this entry is encountered, the sender of the packet will omit the trailing Suffix Length bytes from all the remaining entries and the receiver will process the packet as if Suffix Length zeroes were to be appended to each address entry. It is permissible to have multiple "Omitted Suffix" operators in single packet. 3.6. Restore Virginity +---------------+ | Type = 8 | +---------------+ When this entry is encountered, the sender of the packet will revert to the encoding specified in [1], and the receiver will apply those rules until further instructed. It is permissible to have multiple "Restore Virginity" operators in single packet. 4. References [1] Malkin, G. "Rip for IPv6", Work in Progress. 5. Author's Address Keith Sklower Computer Science Department 380 Soda Hall, Mail Stop 1776 University of California Berkeley, CA 94720-1776 Phone: (510) 642-9587 Sklower [Page 4] Draft RIPv6 Option December 1994 E-mail: sklower@CS.Berkeley.EDU 6. Expiration Date of this Draft May 1, 1995 Sklower [Page 5]
- A modest proposal . . . (a la swift). Keith Sklower