Network Working Group                                          P. Martin
INTERNET-DRAFT                                     Pacific Softworks Inc
                                                                May 1997


          PPP/IPCP Extension for Word Alignment of IP Datagrams
             <draft-rfced-info-martin-00.txt>

Status of this Memo

This document is 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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
   The PPP/IPCP extension for 32 bit Alignment of IP datagrams provides
   a method to negotiate and align IP datagrams on a 32 bit boundary.
   This document describes the use of the Internet Protocol Control
   Protocol (IPCP) [2] option and the PPP framing that is required for
   alignment of all IP datagrams.


Table of Contents

   1.     Introduction ..........................................    2

   1.1.   Specification of Requirements .........................    2

   2.1    Configuration Option Format ...........................    3

   3.1    Frame Format ..........................................    4

   SECURITY CONSIDERATIONS ......................................    5

   REFERENCES ...................................................    5

   CHAIR'S ADDRESS    ...........................................    5

   AUTHORS' ADDRESS .............................................    5






Martin                       Informational                      [Page 1]


^L

I/D                       PPP IP Padding                      May 1997

1.  Introduction

    Many processors today are 32 bit word bound.  This is especially
    true for processors like the TI TMS320C3X.  Other processors are
    16 bit word bound like the Motorola 68000.  Today with the ever
    increasing use of microcontrollers that are used to convey IP
    datagrams to the home in consumer electronic devices, it is
    becoming more and more important to leave an IP datagram aligned
    on a 32 bit boundary for performance.  The cost of building these
    consumer electronic devices is so sensitive that the minimum
    amount of RAM, ROM and processing power are used.  For these devices
    an addition to the IPCP protocol needed to be defined that will add
    a simple padding character to the data stream to allow the IP
    datagram to remain on a word bit boundary.  The proposed solution is
    designed to require the minimum overhead in code, ram, and
    processing requirements to achieve the goal of leaving the IP
    datagram in it's orignal word boundary state.  The effects of
    compression on the packet (like Protocol Field, Address/Control
    field and Van-Jacobson compression), cause the microcontroller to
    either spend a lot of time processing the packet in order to get it
    aligned or force the microcontroller not to gain the benefits of
    these compression techniques.


1.1.  Specification of Requirements

    A new IPCP option SHALL be added to negotiate the desire to have IP
    datagrams aligned on a negotiated octet boundary.  Upon successful
    negotiation of the IP Padding Option, the Acknowledger of the
    request SHALL pad prior to the IP datagram with zero to the
    negotiated alignment value - 1 octets with the negotiated the pad
    character for all PPP frames containing an IP datagram.  These MUST
    be identified by the protocol field containing the following values:

    0021  IP Datagram
    002D  VJ Compressed TCP/IP Datagram
    002E  Uncompressed TCP/IP Datagram

    The implementation MAY be extended to provide for other compressed
    IP Datagrams not yet defined.

    The requesting system SHOULD discard the pad character(s) when
    passing the datagram to the upper layers.  The requesting system MAY
    also check the IP Datagram to verify that it is on the word boundary
    that was requested.








Martin                       Informational                      [Page 2]


^L

I/D                      PPP IP Padding                      May 1997

2.1.   IPCP Option Negotiation

   A new negotiation option is added for 32 bit padding.  If the
   receiver of such an option acknowledges this option then the
   receiver SHALL send all IP datagrams with the padding character
   sufficient to force the IP datagram (after unstuffing and
   decompression) to a 32 bit aligned value within the frame.


   IP Padding Option

    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Alignment    | Pad Character |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

   64 (0x40)


   Length

   4


   Alignment

   Number of octets to align to:
   1  No Alignment
   2  16 bit Alignment
   4  32 Bit Alignment
   8  64 Bit Alignment
   16 128 bit Alignment


   Pad Character

   The character to be used for padding



   An example for 32 bit alignment using 0xFE for the PAD Character

    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x40      |     0x04      |     0x04      |      0xFE     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Martin                       Informational                      [Page 3]


^L

I/D                       PPP IP Padding                      May 1997

3.1.  Frame Format

   If the IP Padding Option is successfully negotiated, then the
   acknowledger of that option SHALL send all IP datagrams with
   the following format.  This will allow the system requesting
   the IP Padding Option to assume that all IP datagrams before
   passing to the network layer will be aligned to a negotiated
   boundary.

   The PPP frame is padded following the Protocol Field so that the
   beginning of the IP datagram is placed on the requested word
   boundary after all unstuffing and decompression take place.
   The pad character to be used SHALL be the one negotiated in the
   IPCP option 64.


   Examples of Padding taking place with 32 bit alignment and the pad
   character being 0xFE.

   1.   Protocol Field Compression

    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      FF       |       03      |       21      |    FE (PAD)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      IP Datagram
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   2.   Protocol & Address/Control Field Compression

    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      21       |    FE (PAD)   |    FE (PAD)   |    FE (PAD)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      IP Datagram
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   3.   Van-Jacobson Compression

    0                   1                   2                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      FF       |      03       |       00      |       2D      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      FE (PAD) |      VJ Compressed TCP/IP Header              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TCP Payload...                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Martin                       Informational                      [Page 4]

^L

I/D                        PPP IP Padding                      May 1997


Security Considerations

    Security issues are not discussed in this memo.

References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, Daydreamer, July 1994.
   [2]   McGregor, G.,  "The (PPP) Internet Protocol Control Protocol
              (IPCP)", RFC 1332, Merit, May     1992.
   [3]   Postel, J., "Internet Protocol", RFC 791, USC/Information
         Sciences Institute, September 1981.
   [4]   Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January
         1990.
   [5]   Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
         1340, USC/Information Sciences Institute, July 1992.



Chair's Address

   The working group can be contacted via the current chair:

         Karl F. Fox
         Ascend Communications
         3518 Riverside Dr., Suite 101
         Columbus, Ohio  43221
         (614) 451-1883
         EMail: karl@ascend.ComAuthor's Address

   Questions about this memo can also be directed to:

         Paul S. Martin
         Pacific Softworks Inc.
         4000 Via Pescador
         Camarillo, CA  93012
         (805)484-2128
         Email: paulmart@microsoft.com



INTERNET-DRAFT           EXPIRES JANUARY  1998            INTERNET-DRAFT