home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ippcp / ippcp-charter.txt < prev    next >
Encoding:
Text File  |  1997-10-22  |  5.1 KB  |  120 lines
  1.  
  2. IP Payload Compression Protocol (ippcp)
  3. ---------------------------------------
  4.  
  5.  Charter 
  6.  Last Modified: 21-Jul-97
  7.  
  8.  Current Status: Active Working Group
  9.  
  10.  Chair(s):
  11.      Naganand Doraswamy <naganand@baynetworks.com>
  12.  
  13.  Internet Area Director(s): 
  14.      Jeffrey Burgan  <burgan@home.net>
  15.      Thomas Narten  <narten@raleigh.ibm.com>
  16.  
  17.  Internet Area Advisor: 
  18.      Thomas Narten  <narten@raleigh.ibm.com>
  19.  
  20.  Mailing Lists: 
  21.      General Discussion:ippcp@external.cisco.com
  22.      To Subscribe:      mailer@cisco.com
  23.          In Body:       subscribe/unsubscribe ippcp [email_addr] in body
  24.      Archive:           ftp://ftp-eng.cisco.com/ippcp/ippcp
  25.  
  26. Description of Working Group:
  27.  
  28. Lossless data compression has commonly been deployed in layers below IP
  29. (PPP being one example). However, the anticipated deployment of
  30. higher-layer encryption protocols (e.g., IPSec) threatens to reduce the
  31. effectiveness of lower-layer compression techniques since encrypted
  32. data cannot be compressed.  The IP Payload Compression Protocol Working
  33. Group will develop protocol specifications that make it possible to
  34. perform lossless compression on individual payloads before the payload
  35. is processed by a protocol that encrypts it. These specifications will
  36. allow for compression operations to be performed prior to the
  37. encryption of a payload by such protocols as IPSec.
  38.  
  39. The Working Group will focus on the compression of independent payloads
  40. (i.e., independent datagrams) in a stateless manner. By stateless, we
  41. mean that decompression of a received packet does not rely on correct
  42. reception or correct ordering of previous packets.
  43.  
  44. The immediate problem the Working Group will address is the development
  45. of a payload compression protocol for use in conjunction with IPSec.
  46. The working group will develop its specifications to support both IPv4
  47. and IPv6. Although the primary motivation for this WG is the need to
  48. compress packets when IPSec is used, the WG will develop an
  49. architecture that does not preclude its use with other potential
  50. protocols or the absence of IPSec.
  51.  
  52. The working group will identify and document the mechanisms that allow
  53. two communicating parties to negotiate the use of compression as well
  54. as the compression format to be employed. The Working Group will
  55. consider defining extensions to ISAKMP to support the negotiation of
  56. compression parameters. Use of ISAKMP as the immediate effort shall not
  57. preclude compression in the absence of IPsec.  Alternate negotiation
  58. mechanisms (or even static negotiation), if appropriate, shall be
  59. identified and extended as needed to accommodate the use of payload
  60. compression functionality. Since compression will be negotiated,
  61. existing implementations of IP will interoperate with implementations
  62. that support compression.
  63.  
  64. The output of this WG will consist of a base architectural document
  65. that provides the framework for how compression will be done (i.e.,
  66. defines the compression "shim"), together with one or more documents
  67. giving specific compression algorithms and formats. The architectural
  68. document will describe how different compression algorithms can be
  69. negotiated and supported, but the documenting of specific compression
  70. algorithms will be done elsewhere (i.e., in standalone documents). A
  71. registration mechanism for various compression formats will be
  72. specified as part of the base protocol. If possible, an existing
  73. registration mechanism for compression formats shall be used (e.g.,
  74. Compression Control Protocol options of PPP).
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  Goals and Milestones: 
  82.  
  83.    Jul 97       Submit Internet-Draft on Base Architecture for IP Payload 
  84.                 Compression Protocol                                           
  85.  
  86.    Jul 97       Solicit drafts of compressed data formats from working group   
  87.  
  88.    Aug 97       Meet in Munich to discuss submitted drafts                     
  89.  
  90.    Aug 97       Revise drafts to reflect working group discussion/inputs       
  91.  
  92.    Oct 97       Submit IP Payload Compression Protocol architectural document 
  93.                 to the IESG for consideration as a Proposed Standard.          
  94.  
  95.    Oct 97       Submit specific compression transform document(s) to the IESG 
  96.                 for consideration as a Proposed Standard or as Informational 
  97.                 RFC.                                                           
  98.  
  99.    Oct 97       Submit document definining mechanism for using ISAKMP to 
  100.                 negotiate compression formats to the IESG for consideration as 
  101.                 Proposed Standard.                                             
  102.  
  103.    Dec 97       Meet in Washington, DC to discuss implementation issues 
  104.                 relating to IP Payload Compression Protocol, compressed data 
  105.                 format drafts, and possible future work of the group           
  106.  
  107.    Jan 98       AD review of WG. Revise charter or close group down.           
  108.  
  109.  
  110.  Internet-Drafts:
  111.  
  112. Posted Revised       I-D Title  <Filename>
  113. ------ ------- ------------------------------------------
  114.  Jul 97 Oct 97  <draft-ietf-ippcp-protocol-01.txt> 
  115.                 IP Payload Compression Protocol (IPComp)                       
  116.  
  117.  Request For Comments:
  118.  
  119.   None to date.
  120.