doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc2364.txt b/doc/rfc/rfc2364.txt
new file mode 100644
index 0000000..087acd3
--- /dev/null
+++ b/doc/rfc/rfc2364.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           G. Gross
+Request for Comments: 2364                           Lucent Technologies
+Category: Standards Track                                      M. Kaycee
+                                                                Paradyne
+                                                                  A. Lin
+                                                         Shasta Networks
+                                                                A. Malis
+                                                   Ascend Communications
+                                                             J. Stephens
+                                                          Cayman Systems
+                                                               July 1998
+
+
+                             PPP Over AAL5
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+
+   This document describes the use of ATM Adaptation Layer 5 (AAL5) for
+   framing PPP encapsulated packets.
+
+Applicability
+
+   This specification is intended for those implementations which desire
+   to use the facilities which are defined for PPP, such as the Link
+   Control Protocol, Network-layer Control Protocols, authentication,
+   and compression.  These capabilities require a point-to-point
+   relationship between the peers, and are not designed for the multi-
+   point relationships which are available in ATM and other multi-access
+   environments.
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 1]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+1. Introduction
+
+   ATM AAL5 protocol is designed to provide virtual connections between
+   end stations attached to the same network.  These connections offer a
+   packet delivery service that includes error detection, but does not
+   do error correction.
+
+   Most existing implementations of PPP use ISO 3309 HDLC as a basis for
+   their framing [3].
+
+   When an ATM network is configured with point-to-point connections,
+   PPP can use AAL5 as a framing mechanism.
+
+2. Conventions
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [10].
+
+3. AAL5 Layer Service Interface
+
+   The PPP layer treats the underlying ATM AAL5 layer service as a bit-
+   synchronous point-to-point link.  In this context, the PPP link
+   corresponds to an ATM AAL5 virtual connection.  The virtual
+   connection MUST be full-duplex, point to point, and it MAY be either
+   dedicated (i.e. permanent, set up by provisioning) or switched (set
+   up on demand).  In addition, the PPP/AAL5 service interface boundary
+   MUST meet the following requirements:
+
+        Interface Format - The PPP/AAL5 layer boundary presents an octet
+        service interface to the AAL5 layer.  There is no provision for
+        sub-octets to be supplied or accepted.
+
+        Transmission Rate - The PPP layer does not impose any
+        restrictions regarding transmission rate or the underlying ATM
+        layer traffic descriptor parameters.
+
+        Control Signals - The AAL5 layer MUST provide control signals to
+        the PPP layer which indicate when the virtual connection link
+        has become connected or disconnected.  These provide the "Up"
+        and
+
+        "Down" events to the LCP state machine [1] within the PPP layer.
+
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 2]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+4. Multi-Protocol Encapsulation
+
+   This specification uses the principles, terminology, and frame
+   structure described in "Multiprotocol Encapsulation over ATM
+   Adaptation Layer 5" [4].
+
+   The purpose of this specification is not to document what is already
+   standardized in [4], but to specify how the mechanisms described in
+   [4] are to be used to map PPP onto an AAL5-based  ATM network.
+   Section 1 within [4] defines the two mechanisms for identifying the
+   Protocol Data Unit (PDU) payload field's protocol type: virtual
+   circuit based multiplexing, and Logical Link Control (LLC)
+   encapsulation.  In the former technique, the payload's protocol type
+   is implicitly agreed to by the end points for each virtual circuit
+   using provisioning or control plane procedures.  When using the LLC
+   encapsulation technique, the payload's protocol type is explicitly
+   identified on a per PDU basis by an in-band LLC header, followed by
+   the payload data.
+
+   When transporting a PPP payload over AAL5, an implementation:
+
+        1. MUST support virtual circuit multiplexed PPP payloads as
+        described in section 5 below by mutual configuration or
+        negotiation of both end points.  This technique is referred to
+        as "VC-multiplexed PPP".
+
+        2. MUST support LLC encapsulated PPP payloads on PVCs as
+        described in section 6 below by mutual configuration or
+        negotiation of both end points.  This technique is referred to
+        as "LLC encapsulated PPP".
+
+        3. For SVC set up, an implementation MUST negotiate using the
+        Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
+        Interface (B-LLI) information element to signal either VC-
+        multiplexed PPP or LLC encapsulated PPP.  The details of this
+        control plane procedure are described in section 7.
+
+   If an implementation is connecting through a Frame Relay/ATM FRF.8
+   [7] service inter-working unit to an RFC 1973 [6] end point, then it
+   MUST use LLC encapsulated PPP payloads.  Frame Relay/ATM FRF.8
+   inter-working units are exempted from the requirement to support VC-
+   multiplexed PPP.  This exemption allows the FR/ATM IWU to remain
+   compliant with FRF.8 when the PPP over AAL5 end point is inter-
+   operating with an RFC 1973 end point.
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 3]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+5. Virtual Circuit Multiplexed PPP Over AAL5
+
+   The AAL5 PDU format is shown in figure 1:
+
+                        AAL5 CPCS-PDU Format
+                  +-------------------------------+
+                  |             .                 |
+                  |             .                 |
+                  |        CPCS-PDU Payload       |
+                  |     up to 2^16 - 1 octets)    |
+                  |             .                 |
+                  +-------------------------------+
+                  |      PAD ( 0 - 47 octets)     |
+                  +-------------------------------+ -------
+                  |       CPCS-UU (1 octet )      |    ^
+                  +-------------------------------+    |
+                  |         CPI (1 octet )        |    |
+                  +-------------------------------+CPCS-PDU Trailer
+                  |        Length (2 octets)      |    |
+                  +-------------------------------|    |
+                  |         CRC (4 octets)        |    V
+                  +-------------------------------+ -------
+                                   Figure 1
+
+   The Common Part Convergence Sub-layer (CPCS)-PDU Payload field
+   contains user information up to 2^16 - 1 octets.
+
+   The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
+   such that the last 48 octet cell payload created by the SAR sublayer
+   will have the CPCS-PDU Trailer right justified in the cell.
+
+   The CPCS-UU (User-to-User indication) field is used to transparently
+   transfer CPCS user to user information.  The field has no function
+   under the multi-protocol ATM encapsulation described in this memo and
+   can be set to any value.
+
+   The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
+   64 bits.  Possible additional functions are for further study in
+   ITU-T.  When only the 64 bit alignment function is used, this field
+   shall be coded as 0x00.
+
+   The Length field indicates the length, in octets, of the Payload
+   field.  The maximum value for the Length field is 65535 octets.  A
+   Length field coded as 0x00 is used for the abort function.
+
+   The CRC field protects the entire CPCS-PDU except the CRC field
+   itself.
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 4]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+   A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and
+   is defined as:
+
+               +-------------+-------------+---------+
+               | Protocol ID | Information | Padding |
+               |  8/16 bits  |             |         |
+               +-------------+-------------+---------+
+                                Figure 2
+
+   Each of these fields are specifically defined in [1].
+
+6. LLC Encapsulated PPP Over AAL5
+
+   LLC encapsulated PPP over AAL5 is the alternative technique to VC-
+   multiplexed PPP over AAL5.
+
+   The AAL5 CPCS-PDU payload  field is encoded as shown in figure 3.
+   The pertinent fields in that diagram are:
+
+        1. LLC header: 2 bytes encoded to specify a source SAP and
+        destination SAP of routed OSI PDU (values 0xFE 0xFE), followed
+        by an Un-numbered Information (UI) frame type (value 0x03).
+
+        2. Network Layer Protocol IDentifier (NLPID) representing PPP,
+        (value 0xCF).
+
+        3. the PPP protocol identifier field, which can be either 1 or 2
+        octets long.  See reference [1].
+
+        4. followed by the PPP information field as per Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 5]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+                  +-------------------------+ --------
+                  |  Destination SAP (0xFE) |     ^
+                  +-------------------------+     |
+                  |  Source SAP (0xFE)      | LLC header
+                  +-------------------------+     |
+                  |  Frame Type = UI (0x03) |     V
+                  +-------------------------+ --------
+                  |  NLPID = PPP (0xCF)     |
+                  +-------------------------+ --------
+                  |   Protocol Identifier   |     ^
+                  |     (8 or 16 bits)      |     |
+                  +-------------------------+ PPP payload
+                  |          .              |     |
+                  |          .              |     |
+                  |  PPP information field  |     |
+                  |          .              |     |
+                  |          .              |     |
+                  +-------------------------+     |
+                  |        padding          |     V
+                  +-------------------------+ --------
+                  |  PAD ( 0 - 47 octets)   |
+                  +-------------------------+ --------
+                  |  CPCS-UU (1 octet )     |     ^
+                  +-------------------------+     |
+                  |    CPI (1 octet )       |     |
+                  +-------------------------+CPCS-PDU Trailer
+                  |   Length (2 octets)     |     |
+                  +-------------------------|     |
+                  |    CRC (4 octets)       |     V
+                  +-------------------------+ --------
+
+
+                             Figure 3
+
+   The end points MAY be bi-laterally provisioned to send other LLC-
+   encapsulated protocols besides PPP across the same virtual
+   connection.  However, they MUST NOT send packets belonging to any
+   protocol that has an active NCP within the PPP session.
+   Implementations SHOULD do packet scheduling that minimizes the
+   performance impact on the quality of service commitments associated
+   with both the LLC-encapsulated PPP and non-PPP protocol flows.
+
+7. Out-Of-Band Control Plane Signaling
+
+   When originating a switched virtual circuit AAL5 connection, the
+   caller MUST request in the SETUP message either VC-multiplexed PPP,
+   LLC-encapsulated PPP, or else both VC-multiplexed and LLC-
+   encapsulated PPP.  When a caller is offering both techniques, the two
+
+
+
+Gross, et. al.              Standards Track                     [Page 6]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+   B-LLI IEs are encoded within a Broadband Repeat Indicator IE in the
+   order of their preference.  The called implementation MUST be able to
+   accept an incoming call that offers LLC-encapsulated PPP in the
+   caller's request.  The called implementation MUST reject a call set
+   up request that only offers an encapsulation that it does not
+   support.  Implementations originating a call offering both protocol
+   encapsulation techniques MUST be able to negotiate the use of LLC-
+   encapsulated PPP.
+
+   When originating a virtual circuit multiplexed call that is to carry
+   a PPP payload, the ITU Q.2931 [9] B-LLI element user information
+   layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5] in
+   octet 7.  The extension octets specify an IPI value of PPP (0xCF).
+   By definition, the first bytes of the AAL5 frame's payload field will
+   always contain a PPP header followed by a packet.
+
+   When originating an LLC encapsulated call that is to carry a PPP
+   payload, the ITU Q.2931 B-LLI element user information layer 2
+   protocol field is encoded to select LAN Logical Link Control
+   (ISO/IEC8802-2) in octet 6.  See RFC 1755 [8] appendix A for an
+   example.  By definition, the first bytes of the AAL5 frame's payload
+   field will contain an LLC header, followed by a NLPID and the PPP
+   payload.
+
+8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions
+
+   When the virtual connection loses state, the PPP encapsulation
+   technique may uni-laterally and unexpectedly change across such
+   transitions.  Detection and recovery procedures are defined for the
+   following state transitions:
+
+        VC-multiplexed PPP changing to LLC encapsulated PPP
+
+        LLC encapsulated PPP changing to VC-multiplexed PPP
+
+   When LLC-encapsulated PPP is being used, the inital 6 octets of the
+   LCP packets contain the sequence: fe-fe-03-cf-c0-21.  This sequence
+   constitutes the first 6 octets of the AAL5 frame.  In the case of
+   VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
+   This sequence constitutes the first 2 octets of an AAL5 frame.  When
+   a LCP Configure-Request packet is received and recognized, the PPP
+   link enters Link Establishment phase.
+
+   Once PPP has entered the Network-layer Protocol phase, and
+   successfully negotiated a particular NCP for a PPP Protocol, if a
+   frame arrives using an alternate but equivalent data encapsulation as
+   defined in [4], then the PPP Link MUST:
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 7]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+        For a SVC, immediately clear the call with the cause value 111,
+        "protocol error, unspecified".
+
+        For a PVC: tear down the active NCPs, SHOULD generate an error
+        message, enter the Termination state, and silently drop all
+        received packets.
+
+   These policies prevent "black-holes" that occur when the peer loses
+   state.  An implementation which requires PPP link configuration, and
+   other PPP negotiated features (such as authentication), MAY enter
+   Termination state when configuration fails.
+
+9. LCP Configuration Options
+
+   The Magic Number LCP configuration option is RECOMMENDED, and the
+   Protocol Field Compression (PFC) option is NOT RECOMMENDED.  An
+   implementation MUST NOT request any of the following options, and
+   MUST reject a request for such an option:
+
+        Field Check Sequence (FCS) Alternatives,
+
+        Address-and-Control-Field-Compression (ACFC),
+
+        Asynchronous-Control-Character-Map (ACCM)
+
+   The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
+   larger size than the maximum CPCS-SDU size specified in the
+   associated direction for the virtual connection's traffic contract.
+
+   When viewed peer to peer, a PPP link may be bridged over multiple
+   physical layer sections.  For each such AAL5 section, the LCP framing
+   options MUST be actively negotiated by the bridging convertors
+   independently of the LCP framing options in use by other physical
+   layer sections.
+
+   Implementation Note:
+        When an ATM AAL5 PVC is in the "Stopped" state, it is
+        RECOMMENDED that the implementation wait for Configure-Requests.
+        See the implementation option in reference [1] section 4.2, the
+        "Stopped State" sub-section.
+
+10. Security Considerations
+
+   Generally, ATM networks are virtual circuit based, and security is
+   implicit in the public data networking service provider's
+   administration of Permanent Virtual Circuits (PVCs) between the
+   network boundaries.  The probability of a security breach caused by
+   mis-routed ATM cells is considered to be negligible.
+
+
+
+Gross, et. al.              Standards Track                     [Page 8]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+   When a public ATM network supports Switched Virtual Circuits, the
+   protocol model becomes analogous to traditional voice band modem dial
+   up over the Public Telephone Switched Network (PTSN).  The same
+   PAP/CHAP authentication protocols that are already widely in use for
+   Internet dial up access are leveraged.  As a consequence, PPP over
+   AAL5 security is at parity with those practices already established
+   by the existing Internet infrastructure.
+
+   Those applications that require stronger security are encouraged to
+   use authentication headers, or encrypted payloads, and/or ATM-layer
+   security services.
+
+   When using LLC-encapsulated PPP over a virtual connection, an end
+   point can not assume that the PPP session authentication and related
+   security mechanisms also secure the other LLC encapsulated flows on
+   that same virtual connection.
+
+11. Acknowledgments
+
+   This design is based on work performed in ADSL Forum's Packet Mode
+   Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973, by
+   William Simpson.  Special thanks to Phil Rakity of Flowpoint, Tim
+   Kwok of Microsoft, and David Allan of Nortel for their constructive
+   review and commentary.
+
+12. References
+
+   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+         51, RFC 1661, July 1994.
+
+   [2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
+         Specification v2", af-saa-0088.000, May 1997.
+
+   [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
+         1662, July 1994.
+
+   [4]   Heinanen, J., "Multiprotocol Interconnect over AAL5", RFC 1483,
+         July 1993.
+
+   [5]   ISO/IEC DTR 9577.2, "Information technology -
+         Telecommunications and Information exchange between systems -
+         Protocol Identification in the network layer", 1995-08-16.
+
+   [6]   Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
+
+   [7]   The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-
+         working Implementation Agreement", FRF.8, April 1995.
+
+
+
+
+Gross, et. al.              Standards Track                     [Page 9]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+   [8]   Perez, M., Liaw, F., Mankin, A., Hoffman, E., Grossman, D., and
+         A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755,
+         February 1995.
+
+   [9]   International Telecommunication Union, "Broadband Integrated
+         Service Digital Network (B-ISDN) Digital Subscriber Signaling
+         System No.2 (DSS2) User Network Interface Layer 3 Specification
+         for Basic Call/Connection Control", ITU-T Recommendation
+         Q.2931, (International Telecommunication Union: Geneva, 2/95)
+
+   [10]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Karl Fox
+   Ascend Communications
+   3518 Riverside Drive, Suite 101
+   Columbus, Ohio 43221
+
+   EMail: karl@ascend.com
+
+Authors' Addresses
+
+   Questions about this memo can also be directed to:
+
+   George Gross
+   Lucent Technologies, Inc
+   184 Liberty Corner Road
+   Warren, NJ 07059
+
+   Phone:   +1.908.580.4589
+   EMail: gmgross@lucent.com
+
+
+   Manu Kaycee
+   Paradyne Corporation
+   21 Bear Meadow Road
+   Londonderry, NH 03053-2168
+
+   Phone: +1.603.434.6088
+   EMail: mjk@nj.paradyne.com
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                    [Page 10]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+   Arthur Lin
+   Shasta Networks Inc.
+   249 Humboldt Court
+   Sunnyvale, CA 94089-1300
+
+   Phone: +1.408.747.5051
+   EMail: alin@shastanets.com
+
+
+   Andrew Malis
+   Ascend Communications, Inc.
+   1 Robbins Road
+   Westford, MA 01886
+
+   Phone: +1.978.952.7414
+   EMail: malis@ascend.com
+
+
+   John Stephens
+   Cayman Systems, Inc.
+   100 Maple Street
+   Stoneham, MA 02180
+
+   Phone: +1.617.279.1101
+   EMail: john@cayman.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                    [Page 11]
+
+RFC 2364                     PPP Over AAL5                     July 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross, et. al.              Standards Track                    [Page 12]
+