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, 4 Dec 1994 21:06:40 -0800 (PST)
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]