home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-martin-00.txt < prev    next >
Text File  |  1997-07-01  |  10KB  |  286 lines
  1.  
  2. Network Working Group                                          P. Martin
  3. INTERNET-DRAFT                                     Pacific Softworks Inc
  4.                                                                 May 1997
  5.  
  6.  
  7.           PPP/IPCP Extension for Word Alignment of IP Datagrams
  8.              <draft-rfced-info-martin-00.txt>
  9.  
  10. Status of this Memo
  11.  
  12. This document is an Internet-Draft. Internet-Drafts are working
  13. documents of the Internet Engineering Task Force (IETF), its areas,
  14. and its working groups. Note that other groups may also distribute
  15. working documents as Internet-Drafts.
  16.  
  17. Internet-Drafts are draft documents valid for a maximum of six months
  18. and may be updated, replaced, or obsoleted by other documents at any
  19. time. It is inappropriate to use Internet-Drafts as reference material
  20. or to cite them other than as "work in progress."
  21.  
  22. To learn the current status of any Internet-Draft, please check the
  23. "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  24. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  25. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  26. ftp.isi.edu (US West Coast).
  27.  
  28. Abstract
  29.  
  30.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  31.    transporting multi-protocol datagrams over point-to-point links.
  32.    The PPP/IPCP extension for 32 bit Alignment of IP datagrams provides
  33.    a method to negotiate and align IP datagrams on a 32 bit boundary.
  34.    This document describes the use of the Internet Protocol Control
  35.    Protocol (IPCP) [2] option and the PPP framing that is required for
  36.    alignment of all IP datagrams.
  37.  
  38.  
  39. Table of Contents
  40.  
  41.    1.     Introduction ..........................................    2
  42.  
  43.    1.1.   Specification of Requirements .........................    2
  44.  
  45.    2.1    Configuration Option Format ...........................    3
  46.  
  47.    3.1    Frame Format ..........................................    4
  48.  
  49.    SECURITY CONSIDERATIONS ......................................    5
  50.  
  51.    REFERENCES ...................................................    5
  52.  
  53.    CHAIR'S ADDRESS    ...........................................    5
  54.  
  55.    AUTHORS' ADDRESS .............................................    5
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. Martin                       Informational                      [Page 1]
  63. ^L
  64.  
  65. I/D                       PPP IP Padding                      May 1997
  66.  
  67. 1.  Introduction   
  68.  
  69.     Many processors today are 32 bit word bound.  This is especially 
  70.     true for processors like the TI TMS320C3X.  Other processors are
  71.     16 bit word bound like the Motorola 68000.  Today with the ever
  72.     increasing use of microcontrollers that are used to convey IP
  73.     datagrams to the home in consumer electronic devices, it is 
  74.     becoming more and more important to leave an IP datagram aligned
  75.     on a 32 bit boundary for performance.  The cost of building these
  76.     consumer electronic devices is so sensitive that the minimum 
  77.     amount of RAM, ROM and processing power are used.  For these devices
  78.     an addition to the IPCP protocol needed to be defined that will add
  79.     a simple padding character to the data stream to allow the IP 
  80.     datagram to remain on a word bit boundary.  The proposed solution is 
  81.     designed to require the minimum overhead in code, ram, and 
  82.     processing requirements to achieve the goal of leaving the IP 
  83.     datagram in it's orignal word boundary state.  The effects of
  84.     compression on the packet (like Protocol Field, Address/Control 
  85.     field and Van-Jacobson compression), cause the microcontroller to 
  86.     either spend a lot of time processing the packet in order to get it
  87.     aligned or force the microcontroller not to gain the benefits of 
  88.     these compression techniques.
  89.  
  90.     
  91. 1.1.  Specification of Requirements    
  92.  
  93.     A new IPCP option SHALL be added to negotiate the desire to have IP 
  94.     datagrams aligned on a negotiated octet boundary.  Upon successful 
  95.     negotiation of the IP Padding Option, the Acknowledger of the 
  96.     request SHALL pad prior to the IP datagram with zero to the 
  97.     negotiated alignment value - 1 octets with the negotiated the pad 
  98.     character for all PPP frames containing an IP datagram.  These MUST
  99.     be identified by the protocol field containing the following values:
  100.     
  101.     0021  IP Datagram
  102.     002D  VJ Compressed TCP/IP Datagram
  103.     002E  Uncompressed TCP/IP Datagram
  104.     
  105.     The implementation MAY be extended to provide for other compressed
  106.     IP Datagrams not yet defined.
  107.     
  108.     The requesting system SHOULD discard the pad character(s) when 
  109.     passing the datagram to the upper layers.  The requesting system MAY
  110.     also check the IP Datagram to verify that it is on the word boundary
  111.     that was requested.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120. Martin                       Informational                      [Page 2]
  121. ^L
  122.  
  123. I/D                      PPP IP Padding                      May 1997
  124.  
  125. 2.1.   IPCP Option Negotiation
  126.  
  127.    A new negotiation option is added for 32 bit padding.  If the
  128.    receiver of such an option acknowledges this option then the
  129.    receiver SHALL send all IP datagrams with the padding character
  130.    sufficient to force the IP datagram (after unstuffing and 
  131.    decompression) to a 32 bit aligned value within the frame.
  132.    
  133.  
  134.    IP Padding Option
  135.  
  136.     0                   1                   2                   3
  137.     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
  138.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  139.    |     Type      |    Length     |  Alignment    | Pad Character |
  140.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  141.  
  142.    Type
  143.    
  144.    64 (0x40)
  145.    
  146.  
  147.    Length
  148.    
  149.    4
  150.    
  151.  
  152.    Alignment
  153.    
  154.    Number of octets to align to:
  155.    1  No Alignment
  156.    2  16 bit Alignment
  157.    4  32 Bit Alignment
  158.    8  64 Bit Alignment
  159.    16 128 bit Alignment
  160.    
  161.    
  162.    Pad Character
  163.    
  164.    The character to be used for padding
  165.    
  166.    
  167.  
  168.    An example for 32 bit alignment using 0xFE for the PAD Character
  169.  
  170.     0                   1                   2                   3
  171.     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
  172.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  173.    |     0x40      |     0x04      |     0x04      |      0xFE     |
  174.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  175.  
  176.    
  177.                        
  178. Martin                       Informational                      [Page 3]
  179. ^L
  180.  
  181. I/D                       PPP IP Padding                      May 1997
  182.  
  183. 3.1.  Frame Format
  184.  
  185.    If the IP Padding Option is successfully negotiated, then the
  186.    acknowledger of that option SHALL send all IP datagrams with
  187.    the following format.  This will allow the system requesting
  188.    the IP Padding Option to assume that all IP datagrams before
  189.    passing to the network layer will be aligned to a negotiated
  190.    boundary.
  191.    
  192.    The PPP frame is padded following the Protocol Field so that the
  193.    beginning of the IP datagram is placed on the requested word
  194.    boundary after all unstuffing and decompression take place.  
  195.    The pad character to be used SHALL be the one negotiated in the 
  196.    IPCP option 64.
  197.    
  198.    
  199.    Examples of Padding taking place with 32 bit alignment and the pad
  200.    character being 0xFE.
  201.    
  202.    1.   Protocol Field Compression
  203.    
  204.     0                   1                   2                   3
  205.     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
  206.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  207.    |      FF       |       03      |       21      |    FE (PAD)   |
  208.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  209.    |      IP Datagram
  210.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  211.  
  212.  
  213.    2.   Protocol & Address/Control Field Compression
  214.    
  215.     0                   1                   2                   3
  216.     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
  217.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  218.    |      21       |    FE (PAD)   |    FE (PAD)   |    FE (PAD)   |
  219.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  220.    |      IP Datagram
  221.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  222.  
  223.  
  224.    3.   Van-Jacobson Compression
  225.    
  226.     0                   1                   2                   3
  227.     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
  228.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  229.    |      FF       |      03       |       00      |       2D      |
  230.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  231.    |      FE (PAD) |      VJ Compressed TCP/IP Header              |
  232.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  233.    | TCP Payload...                                                |
  234.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235.  
  236. Martin                       Informational                      [Page 4]
  237. ^L
  238.  
  239. I/D                        PPP IP Padding                      May 1997
  240.  
  241.  
  242. Security Considerations   
  243.  
  244.     Security issues are not discussed in this memo.
  245.  
  246. References   
  247.  
  248.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  249.          51, RFC 1661, Daydreamer, July 1994.
  250.    [2]   McGregor, G.,  "The (PPP) Internet Protocol Control Protocol
  251.               (IPCP)", RFC 1332, Merit, May     1992.
  252.    [3]   Postel, J., "Internet Protocol", RFC 791, USC/Information
  253.          Sciences Institute, September 1981.
  254.    [4]   Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January
  255.          1990.
  256.    [5]   Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
  257.          1340, USC/Information Sciences Institute, July 1992.
  258.  
  259.  
  260.  
  261. Chair's Address
  262.  
  263.    The working group can be contacted via the current chair:         
  264.  
  265.          Karl F. Fox
  266.          Ascend Communications         
  267.          3518 Riverside Dr., Suite 101
  268.          Columbus, Ohio  43221         
  269.          (614) 451-1883
  270.          EMail: karl@ascend.ComAuthor's Address
  271.  
  272.    Questions about this memo can also be directed to:         
  273.          
  274.          Paul S. Martin
  275.          Pacific Softworks Inc.
  276.          4000 Via Pescador
  277.          Camarillo, CA  93012
  278.          (805)484-2128
  279.          Email: paulmart@microsoft.com
  280.          
  281.  
  282.  
  283. INTERNET-DRAFT           EXPIRES JANUARY  1998            INTERNET-DRAFT
  284.  
  285.  
  286.