rfc1377.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 563 行 · 第 1/2 页


RFC 1377                      PPP OSINLCP                  November 1992


      response.  It is suggested that an implementation give up only
      after user intervention or a configurable amount of time.

   Configuration Option Types

      OSINLCP has one Configuration Option, which is defined below.

2.1.  Sending OSI NPDUs

   Before any Network Protocol Data Units (NPDUs) may be communicated,
   PPP must reach the Network-Layer Protocol phase, and the OSI Network
   Layer Control Protocol must reach the Opened state.

   Exactly one OSI NPDU is encapsulated in the Information field of a
   PPP Data Link Layer frame where the Protocol field indicates type hex
   0023 (OSI Network Layer).

   The maximum length of an OSI NPDU transmitted over a PPP link is the
   same as the maximum length of the Information field of a PPP data
   link layer frame.  Larger NPDUs must be segmented as necessary.  If a
   system wishes to avoid segmentation and reassembly, it should use
   transport layer mechanisms to discourage others from sending large
   PDUs.

2.2.  NPDU Alignment

   OSI protocols have peculiar alignment problems due to the fact that
   they are often encapsulated in data link protocols with odd-length
   headers, while PPP defaults to even-length headers.  A router
   switching an OSI packet may find that the beginning of the packet
   falls on an inconvenient memory boundary when the hardware used to
   transmit the packet to its next hop requires a particular alignment.
   This situation can be addressed by the use of leading zero padding.

   When sending, an implementation MAY insert one to three octets of
   zero between the PPP header and the OSI NPDU.  These zero octets
   correspondingly reduce the maximum length of the NPDU that may be
   transmitted.

   On reception, any such leading zero octets (if present) MUST be
   removed.  Regardless of whether leading zero padding is used, an
   implementation MUST also be able to receive a PPP packet with any
   arbitrary alignment of the NPDU.

2.3.  Network Layer Addressing Information

   OSINLCP does not define a separate configuration option for the
   exchange of OSI Network Layer address information.  Instead, the ES-



Katz                                                            [Page 6]

RFC 1377                      PPP OSINLCP                  November 1992


   IS protocol, ISO 9542, should be used.  This protocol provides a
   mechanism for determining the Network Layer address(es) of the
   neighbor on the link, as well as determining if the neighbor is an
   End System or an Intermediate System.

   A draft addendum to ES-IS [9] is being defined in ISO to add support
   for dynamic address assignment.  This addendum has currently passed
   the formal "Committee Draft" (CD) letter ballot.

3.  OSINLCP Configuration Options

   OSINLCP Configuration Options allow negotiatiation of desirable
   Internet Protocol parameters.  OSINLCP uses the same Configuration
   Option format defined for LCP [1], with a separate set of Options.

   The most up-to-date values of the OSINLCP Option Type field are
   specified in the most recent "Assigned Numbers" RFC [2].  Current
   values are assigned as follows:

      1       Align-NPDU

3.1.  Align-NPDU

   Description

      This Configuration Option provides a way for the receiver to
      negotiate a particular alignment of the OSI NPDU.  Empirical
      evidence suggests that the greatest time deficit for re-alignment
      exists at the receiver.

      The alignment is accomplished through combination of PPP header
      compression with leading zero padding (see above).  It is
      recommended that alignment be entirely through header compression
      combinations whenever possible.  For example, an alignment of 3
      could be achieved by combining uncompressed PPP Address and
      Control fields (2 octets) with a compressed PPP Protocol field (1
      octet).

      This option is negotiated separately in each direction.  A
      receiver which does not need alignment MUST NOT request the
      option.  A sender which desires alignment prior to sending SHOULD
      Configure-Nak with an appropriate value.

         Implementation Note: In a complex environment, there might be
         several conflicting needs for alignment.  It is recommended
         that the receiver request alignment based on the needs of the
         highest speed next hop link.  Also, greater efficiency might be
         obtained by negotiating upstream the values requested by



Katz                                                            [Page 7]

RFC 1377                      PPP OSINLCP                  November 1992


         downstream PPP links, since those packets will not need a
         change in alignment on transit.

      The alignment request is advisory, and failure to agree on an
      alignment MUST NOT prevent the OSINLCP from reaching the Opened
      state.  By default, the alignment is done according to the needs
      of the sender, and all receivers MUST be capable of accepting
      packets with any alignment.

         Vernacular: If you don't like this option, you can refuse to
         negotiate it, and you can send whatever alignment you want.
         However, if you accept the peer's alignment option, then you
         MUST transmit packets with the agreed alignment.

   A summary of the Align-NPDU Configuration Option format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |   Alignment   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1

   Length

      3

   Alignment

      This field specifies the offset of the beginning of the OSI NPDU
      relative to the beginning of the PPP packet header (not including
      any leading Flag Sequences).

      A value of 1 through 4 requires an offset of that specific length,
      modulo 4.  For example, a value of 1 would require no padding when
      the PPP Address, Control, and Protocol fields are compressed.  One
      octet of leading zero padding would be necessary when the PPP
      header is full sized.

      A value of 255 requests an offset of an odd length (1 or 3).  A
      value of 254 requests an offset of an even length (2 or 4).  If
      the sender is not capable of dynamically varying the amount of
      padding, it MUST NAK with one of the two specific values.




Katz                                                            [Page 8]

RFC 1377                      PPP OSINLCP                  November 1992


References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
       Daydreamer, May 1992.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [3] ISO, "Information processing systems -- Data communications --
       Protocol for providing the connectionless-mode network
       service", ISO 8473, 1988.

   [4] ISO, "Information processing systems -- Telecommunications and
       information exchange between systems -- End system to
       Intermediate system Routeing exchange protocol for use in
       conjunction with the protocol for providing the connectionless-
       mode network service (ISO 8473)", ISO 9542, 1988.

   [5] ISO, "Information processing systems -- Telecommunications and
       information exchange between systems -- Intermediate system to
       Intermediate system Intra-Domain routeing exchange protocol for
       use in conjunction with the protocol for providing the
       connectionless-mode network service (ISO 8473)", ISO 10589,
       1990.

   [6] ISO, "Protocol for Exchange of Inter-domain Routeing
       Information among Intermediate Systems to Support Forwarding of
       ISO 8473 PDUs", ISO CD 10747, 1991.

   [7] ISO, "Information technology -- Telecommunications and
       information exchange between systems -- Protocol identification
       in the network layer", ISO/IEC TR9577:1990.

   [8] ISO, "Information processing systems -- Data communications --
       X.25 packet level protocol for Data terminal equipment", ISO
       8208, 1984.

   [9] Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic Discovery
       of OSI NSAP Addresses by End Systems)", SC6/N7248.

Acknowledgments

   Some of the text in this document is taken from previous documents
   produced by the Point-to-Point Protocol Working Group of the Internet
   Engineering Task Force (IETF).

   Special thanks to Ross Callon (DEC), and Cyndi Jung (3Com), for
   contributions of text and design suggestions based on implementation



Katz                                                            [Page 9]

RFC 1377                      PPP OSINLCP                  November 1992


   experience.

   Thanks also to Bill Simpson for his editing and formatting efforts,
   both for this document and for PPP in general.

Security Considerations

   Security issues are not discussed in this memo.

Chair's Address

   The working group can be contacted via the current chair:

   Brian Lloyd
   Lloyd & Associates
   3420 Sudbury Road
   Cameron Park, California 95682

   Phone: [phone]
   EMail: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

   Dave Katz
   cisco Systems, Inc.
   1525 O'Brien Dr.
   Menlo Park, CA  94025

   Phone: [phone]
   EMail: [e-mail]



















Katz                                                           [Page 10]