rfc1553.txt

RFC 的详细文档！

      1  The slot identifer may be compressed.

         The slot identifier must not be compressed if there is no
         ability for the PPP link level to indicate an error in
         reception to the decompression module.  Synchronization after
         errors depends on receiving a packet with the slot identifier.

      2  Redefine Compressed Packet type bits 1-3.

         It was noted earlier that packet types have been chosen such
         that only the Compressed Packet type is an even number value
         with the lowest order bit of zero.  All other packet types are
         odd values with a lowest order bit of one.  The reason for this
         assignment was to make it possible to determine the Compressed
         Packet type by examining only one bit.  This make it possible
         to use all the other 7 bits to indicate status in the
         Compressed Packet.  The 7 bits are composed of the upper 4 bits
         which are permanently defined to indicate packet dependent
         flags, plus bits 1-3 which are otherwise part of the Packet
         Type.  The upper 4 bits are defined above.  The redefinition of
         bits 1-3 of the Compressed Packet type is left for future
         expansion.

               7   6   5   4   3   2   1   0
             +---+---+---+---+---+---+---+---+
             |   |   |   |   |   |   |   | 0 |
             +---+---+---+---+---+---+---+---+
               ^   ^   ^   ^   ^   ^   ^   ^
               |   |   |   |   |   |   |   |___ Packet Type
               |   |   |   |   |   |   |        0    Compressed Packet
               |   |   |   |   |   |   |
               |   |   |   |   |___|___|_______ Redefined bits
               |   |   |   |
               |___|___|___|___________________ Compressed Packet flags

         By default, this feature in not enabled and this flag is
         set to zero.  When this flag is set to one, it indicates



Mathur & Lewis                                                 [Page 18]

RFC 1553                         CIPX                      December 1993


         the desire to use this feature.

Compression Negotiation over IPXWAN Links

   "IPXWAN" is the protocol Novell uses to exchange necessary router
   to router information prior to exchanging standard IPX routing
   information and traffic over WAN datalinks [7].  To negotiate the
   Telebit compression option, we use Novell's allocated option number
   for CIPX (00) in the IPXWAN timer request/response packet.

   The Timer Request packet contains the following Telebit compression
   option:

     WOption Number       80        - Define compression type
     WAccept Option       01        - 0=No, 1=Yes, 3=N/A
     WOption Data Len     00 03     - Length of option
     WOption Data         00        - Telebit's compression (CIPX)
     WOption Data         XX        - Compression options
     WOption Data         NN        - Compression slots

   Where the WOption Data fields are:

     00   Telebit's compression option described in this
          document (CIPX).

     XX   Compression options as defined below:

             0x01   Compress slot ID when possible
             0x02   Redefine Compressed Packet type bits 1-3.

     NN   The requested # of compression slots.

     Accept Option (for compression type) must be set to YES if the
     option is supported and NO if the option is not supported.  A Timer
     Response must respond with only one header compression type set to
     YES.

     The Timer Response packet that accepts the option will look like
     this:

     WOption Number       80        - Define compression type
     WAccept Option       01        - 0=No, 1=Yes, 3=N/A
     WOption Data Len     00 03     - Length of option
     WOption Data         00        - Telebit's compression (CIPX)
     WOption Data         XX        - Compression options
     WOption Data         NN        - Compression slots





Mathur & Lewis                                                 [Page 19]

RFC 1553                         CIPX                      December 1993


   Where the WOption Data fields are:

     00   Telebit's compression option described in this
          document (CIPX).

     XX   Compression options as defined below:

             0x01   Compress slot ID when possible
             0x02   Redefine Compressed Packet type bits 1-3.

     NN   The negotiated # of slots (The lower of each side's
          requested number of slots)

   IPX packets (except of course IPXWAN packets) are not sent over the
   link until the IPXWAN negotiations are completed.  Once IPXWAN
   negotiations are completed, regular IPX packets can be sent over the
   link.

   If both ends of the link agree on the compression options, then the
   IPX packets are sent using the specified options.  If either end of
   the link does not accept a compression option, then this compression
   option will not be used.  Compression will be done using any
   remaining options.  Options, by definition, are not required.
   Implementations MUST support CIPX without any options.

   It is the responsibility of the router sending the IPXWAN Timer
   Response to inform the other router of the options that will be used.
   The Timer Response MUST contain a subset of the options received in a
   Timer Request.

   To be clear, IPXWAN is used to set up a symmetrical compression link.
   Compression is configured identically in both directions.  Each end
   will use the same number of slots and same compression options.  It
   is illegal for link ends to use different number of slots or
   different options.

IPX Compression Performance

   The performance of this algorithm will depend on the number of active
   connections and the number of slots negotiated.  If the number of
   slots is greater than the number of connections, the hit rate should
   be very high giving a very high compression ratio.  The performance
   also depends on the average size of the IPX packets.  If the average
   size of packets is small, then compression will result in a more
   noticeable performance improvement.






Mathur & Lewis                                                 [Page 20]

RFC 1553                         CIPX                      December 1993


                            avg_data_len + uncomp_header_len
        Compression ratio = ----------------------------------
                            avg_data_len + avg_comp_header_len

   Where 'avg_data_len' is the average length of data in the IPX packet,
   and 'uncomp_head_len' is the uncompressed header length which is
   fixed at 30 octets.  Where 'avg_comp_header_len' is the average
   length of the compressed IPX header.  The length of the minimum
   compressed IPX header is 1 octet.  The length of the maximum
   compressed NCP/IPX header is 8 octets (including the NCP task
   number), but since no implementation yet sends packets with a length
   greater than 16K, 7 octets is the commonly encountered maximum.
   Perhaps a reasonable 'avg_comp_header_len' is 2, assuming the
   inclusion of the flag and slot number octets.

   The maximum length of the data in an IPX packet is 546 octets (576
   octets - 30 octet IPX header), although newer implementations may
   send packets of up to 4096 octets.  The minimum length of the data in
   an IPX packet is 1 octet.  Within the normal distribution of small
   NCP packets, perhaps a reasonable 'avg_data_len' is 26 octets.

                                 546 + 30
        Minimal Compression    = -------- =  1.04
                                 546 + 6

                                 1 + 30
        Maximal Compression    = ------   = 15.50
                                 1 + 1

                                 26 + 30
        Likely Compression     = -------  =  2.00
                                 26 + 2


Security Considerations

   IPX provides some security features, which are fully applicable to
   CIPX.  CIPX does not significantly alter the basic security of IPX.













Mathur & Lewis                                                 [Page 21]

RFC 1553                         CIPX                      December 1993


References

   [1] Novell Inc., "IPX Router Specification", September 1992, Part
       Number: 107-000029-001

   [2] Jacobson, Van, "Compressing TCP/IP Headers for Low-Speed Serial
       Links", RFC 1144, February 1990

   [3] CCITT Recommendation V.42bis Error Correcting Procedures for DCEs
       using Error Correction Procedures

   [4] ISO 7776, Information Processing Systems - Data Communication -
       High Level Data Link Control Procedures - Description of the X.25
       LAPB-Compatible DTE Data Link Procedures

   [5] Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1548,
       December 1993

   [6] Simpson, W. A., "The PPP Internet Packet Exchange Control
       Protocol (IPXCP)", RFC 1552, December 1993

   [7] Allen, Michael, "Novell IPX Over Various WAN Media [IPXWAN]",
       RFC 1551, December 1993

Acknowledgements

   This compression algorithm incorporates many ideas from the Van
   Jacobson TCP/IP header compression algorithm.

   Michael Allen from Novell provided a lot of valuable feedback in the
   design of this algorithm.  David Piscitello from Bellcore and Marty
   Del Vecchio at Shiva Corp.  made several good suggestions.  Bill
   Simpson was very helpful in driving PPP, and specifically IPXCP, on
   the standards course.

Chair's Address
      Fred Baker
      Advanced Computer Communications
      315 Bollay Drive
      Santa Barbara, California 93117

      EMail: [e-mail]









Mathur & Lewis                                                 [Page 22]

RFC 1553                         CIPX                      December 1993


Authors' Addresses

      Saroop Mathur
      Telebit Corp.
      1315 Chesapeake Terrace
      Sunnyvale, CA 94089-1100

      EMail: [e-mail]

      Mark S. Lewis
      Telebit Corp.
      1315 Chesapeake Terrace
      Sunnyvale, CA 94089-1100

      EMail: [e-mail]




































Mathur & Lewis                                                 [Page 23]