summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2363.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2363.txt')
-rw-r--r--doc/rfc/rfc2363.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc2363.txt b/doc/rfc/rfc2363.txt
new file mode 100644
index 0000000..a46c7e9
--- /dev/null
+++ b/doc/rfc/rfc2363.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group G. Gross
+Request for Comments: 2363 Lucent Technologies
+Category: Standards Track M. Kaycee
+ Paradyne
+ A. Li
+ Shasta Networks
+ A. Malis
+ Ascend Communications
+ J. Stephens
+ Cayman Systems
+ July 1998
+
+
+ PPP Over FUNI
+
+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 Frame User Network Interface
+ (FUNI) 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 2363 PPP Over FUNI July 1998
+
+
+1. Introduction
+
+ ATM FUNI 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 FUNI 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. FUNI Layer Service Interface
+
+ The PPP layer treats the underlying ATM FUNI layer service as a bit-
+ synchronous point-to-point link. In this context, the PPP link
+ corresponds to an ATM FUNI 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/FUNI service interface boundary
+ MUST meet the following requirements:
+
+ Interface Format - The PPP/FUNI layer boundary presents an octet
+ service interface to the FUNI 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 FUNI 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 2363 PPP Over FUNI 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 a FUNI-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 FUNI, 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 FUNI end point is
+ inter-operating with an RFC 1973 end point.
+
+5. Virtual Circuit Multiplexed PPP Over FUNI
+
+ The FUNI protocol data unit (PDU) format [2] is as follows:
+
+
+
+Gross, et. al. Standards Track [Page 3]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+ +-------------------------------+
+ | Flag |
+ +-------------------------------+---------
+ | FUNI Header | ^
+ +-------------------------------+ |
+ | | |
+ | | |
+ | User SDU | FUNI PDU
+ | | |
+ | | |
+ +-------------------------------+ |
+ | FUNI FCS (2 or 4 octets) | v
+ +-------------------------------+---------
+ | Flag |
+ +-------------------------------+
+ Figure 1
+
+ The FUNI Header includes a 10-bit or 24-bit Frame Address (a.k.a.
+ VPI/VCI bits), a Congestion Notification bit, a Congestion Loss
+ Priority bit, and four Reserved bits.
+
+ The User SDU field contains user information up to 4096 (optionally
+ up to 64K) octets.
+
+ The FCS field protects the entire FUNI PDU except for the FCS field
+ itself.
+
+ A VC-multiplexed PPP frame SHALL constitute the User Service Data
+ Unit (SDU) field and is defined as shown in figure 2:
+
+ +-------------+-------------+---------+
+ | Protocol ID | Information | Padding |
+ | 8/16 bits | | |
+ +-------------+-------------+---------+
+ Figure 2
+
+ Each of these fields are specifically defined in [1].
+
+6. LLC Encapsulated PPP Over FUNI
+
+ LLC encapsulated PPP over FUNI is the alternative technique to VC-
+ multiplexed PPP over FUNI.
+
+ The FUNI SDU payload field is encoded as shown in figure 3. The
+ pertinent fields in that diagram are:
+
+
+
+
+
+
+Gross, et. al. Standards Track [Page 4]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+ 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.
+
+ +-------------------------+ --------
+ | 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
+ +-------------------------+ --------
+ | FUNI FCS (2 or 4 octets)| FUNI trailer
+ +-------------------------+---------
+
+
+ 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.
+
+
+
+
+
+Gross, et. al. Standards Track [Page 5]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+7. Out-Of-Band Control Plane Signaling
+
+ When originating a switched virtual circuit FUNI 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 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 FUNI
+ 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 FUNI 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 FUNI frame. In the case of
+ VC-multiplexed PPP, initial LCP packets contain the sequence c0-21.
+
+
+
+
+Gross, et. al. Standards Track [Page 6]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+ In the case of FUNI, this sequence follows the FUNI Header. 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:
+
+ 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 FUNI 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.
+
+
+
+
+
+
+
+
+Gross, et. al. Standards Track [Page 7]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+ Implementation Note:
+ When an ATM FUNI 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.
+
+ 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
+ FUNI 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross, et. al. Standards Track [Page 8]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+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.
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gross, et. al. Standards Track [Page 9]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+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
+
+
+ Arthur Lin
+ Shasta Networks Inc.
+ 249 Humboldt Court
+ Sunnyvale, CA 94089-1300
+
+ Phone: +1.408.747.5051
+ EMail: alin@shastanets.com
+
+
+
+
+
+
+
+
+
+
+
+Gross, et. al. Standards Track [Page 10]
+
+RFC 2363 PPP Over FUNI July 1998
+
+
+ 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 2363 PPP Over FUNI 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]
+