home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / 94MAR / COMPEN.MIN < prev    next >
Encoding:
Text File  |  1994-05-13  |  6.7 KB  |  174 lines

  1.  
  2. Compression Encapsulation over IP BOF (COMPEN)
  3.  
  4. Reported by Rodney Thayer/Sable Technology
  5.  
  6.  
  7. Summary
  8.  
  9. Twenty-three people attended the COMPEN BOF in Seattle.  It was
  10. generally agreed that there are situations where people have a need for
  11. encapsulation, such as compression.  It was the rough consensus of the
  12. group that if a working group is formed, it should address the general
  13. issue of encapsulation over IP. There was some discussion of whether or
  14. not encapsulation over IP is a problem that is already being solved by
  15. PPP, and whether PPP provides solutions to encapsulation problems.  It
  16. was established that there is enough interest to form a working group on
  17. Generic Encapsulation Over IP, and the COMPEN mailing list will be used
  18. to work together to modify the existing draft charter to reflect the
  19. proposed working group's goals.
  20.  
  21.  
  22. Presentations and Discussion
  23.  
  24. One compression encapsulation scheme was presented by Matt Lukens (see
  25. slides following the minutes:  Figures 1 and 2) and discussed by the
  26. group.  The group also discussed more general requirements for
  27. encapsulation.  Bob Enger (a user, in this context) brought up several
  28. requirements and provided some additional pictures (see slides:  Figure
  29. 3).  Several common points were identified:
  30.  
  31.  
  32.    o Encapsulation of compressed data over IP is the right place to do
  33.      this---it is essentially a routing issue.
  34.  
  35.    o Other groups have addressed the encapsulation problem in several
  36.      different circumstances, that is, encapsulation is something that
  37.      needs standardization.  cisco has authored an informational
  38.      description of their Generic Router Encapsulation protocol; there
  39.      is a scheme for encapsulating IPX; and others are wrestling with
  40.      this issue.
  41.  
  42.    o There is an interest in encapsulators being interoperable.
  43.  
  44.  
  45. Charter for Proposed Working Group
  46.  
  47. The chairs of the proposed COMPEN Working Group will be Rodney Thayer
  48. and Matt Lukens.  The group will be chartered in the Internet Area.
  49.  
  50. Mailing lists already exist for the group.  The general discussion list
  51. is compen@world.std.com.  To subscribe to the list, send a request to
  52. compen-request@world.std.com.  The archive of the list will be located
  53. on ftp.std.com:/pub/compen-archive.
  54.  
  55. The following group description was written before the BOF was held:
  56.  
  57.  
  58.      The Compressed Encapsulation over IP Working Group (COMPEN) is
  59.      chartered to develop a protocol to be used to transmit
  60.      compressed data over IP. The current state of compression
  61.      technology has allowed the development of devices which provide
  62.      the capability to compress IP data.  This working group is
  63.      intended to produce a document which describes a standard
  64.      envelopment protocol that can be used to allow a pair of
  65.      devices to exchanged compressed IP packets.  It is the intent
  66.      of the working group to provide a standard protocol that will
  67.      allow different implementations of compression over IP (of
  68.      which several are now in existence) to interoperate.  There
  69.      also is the need for the capability to support more than one
  70.      compression algorithm, and to support other encapsulation
  71.      schemes, such as encryption, when used in combination with
  72.      compression.
  73.  
  74.      The group wants to provide a standard protocol for use in
  75.      compressing IP data to solve the problem of allowing
  76.      interoperability among devices that support compression.  The
  77.      intent is to solve this interoperability problem by
  78.      establishing a common protocol.  Currently, in order to
  79.      transmit compressed IP over the Internet, the same vendor's
  80.      equipment must be used on both ends.
  81.  
  82.      The development of a standard encapsulation protocol is
  83.      important to the Internet community because the current state
  84.      of the technology allows individual implementations to exist
  85.      that do not interoperate with each other, and yet these
  86.      implementations are present side-by-side in the Internet.  For
  87.      example, several parties are using Internet protocol type 99 to
  88.      represent compressed data using different encapsulation
  89.      schemes.
  90.  
  91.      The development of a protocol for compression over IP is not
  92.      inconsistent with other uses of compression, such as within
  93.      modem standards or link-level protocols such as PPP. This is
  94.      because there are situations where users wish to interconnect
  95.      two nodes through an internetwork and they do not have control
  96.      of all intervening links, and therefore they have to transmit
  97.      IP across the internetwork to connect the two nodes.
  98.  
  99.  
  100. The following goals and milestones were identified before the BOF
  101. session:
  102.  
  103.  
  104. March 94    Meet as a BOF and draft a charter for consideration as an
  105.             IETF working group.  Submit the charter to the area
  106.             directors.
  107.  
  108. June 94     Release a document as an Internet-Draft
  109.  
  110. July 94     Present the Internet-Draft at the IETF meeting.  Revise and
  111.             edit the document as needed.
  112.  
  113. Aug 94      Re-release the Internet-Draft.
  114.  
  115. Nov 94      Submit the Internet-Draft to the IESG for publication as an
  116.             RFC.
  117.  
  118.  
  119. Compression Encapsulation Requirements
  120.  
  121. An outline of compression encapsulation requirements follows the minutes
  122. (Slide 4).
  123.  
  124.  
  125. Proposed Working Group Requirements
  126.  
  127. It was the rough consensus of the attendees that the group requirements
  128. be modified to the following outline:
  129.  
  130.  
  131.    o General tunneling, not just compression
  132.  
  133.    o Specifically address:
  134.       -  Compression
  135.       -  Encryption
  136.       -  No data alteration, just protocol, such as CLNP, Mobile IP,
  137.          Appletalk, etc.
  138.       -  Dynamic negotiation
  139.       -  Fragmentation and expansion
  140.       -  Tunnel re-establishment
  141.  
  142.    o Address whether this is ``different'' from PPP over TCP (or
  143.      something else)
  144.  
  145.    o Address whether this is different from GRE
  146.  
  147.  
  148. Attendees
  149.  
  150. Larry Blunk              ljb@merit.edu
  151. Caralyn Brown            cbrown@wellfleet.com
  152. David Conrad             davidc@iij.ad.jp
  153. Ian Duncan               id@cc.mcgill.ca
  154. Robert Enger             enger@seka.reston.ans.net
  155. Shoji Fukutomi           fuku@furukawa.co.jp
  156. John Houlker             j.houlker@waikato.ac.nz
  157. Jim Hughes               hughes@network.com
  158. Jan-Olof Jemnemo         Jan-Olof.Jemnemo@intg.telia.se
  159. Akira Kato               kato@wide.ad.jp
  160. David Kaufman            dek@magna.telco.com
  161. Sun-Kwan Kimn            sunkimn@cup.hp.com
  162. Ted Kuo                  tik@vnet.ibm.com
  163. Joshua Littlefield       josh@cayman.com
  164. Matt Lukens              mlukens@world.std.com
  165. Gary Malkin              gmalkin@xylogics.com
  166. Gerry Meyer              gerry@spider.co.uk
  167. William Miskovetz        misko@cisco.com
  168. Brad Parker              brad@fcr.com
  169. Doug Schremp             dhs@magna.telco.com
  170. Oscar Strohacker         stroh@vnet.ibm.com
  171. Rodney Thayer            rodney@world.std.com
  172. Walter Wimer             ww0n+@andrew.cmu.edu
  173.  
  174.