rfc2363.txt

中、英文RFC文档大全打包下载完全版 .


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: [e-mail]

Authors' Addresses

   Questions about this memo can also be directed to:

   George Gross
   Lucent Technologies, Inc
   184 Liberty Corner Road
   Warren, NJ 07059

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


   Manu Kaycee
   Paradyne Corporation
   21 Bear Meadow Road
   Londonderry, NH 03053-2168

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


   Arthur Lin
   Shasta Networks Inc.
   249 Humboldt Court
   Sunnyvale, CA 94089-1300

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











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: [phone]
   EMail: [e-mail]


   John Stephens
   Cayman Systems, Inc.
   100 Maple Street
   Stoneham, MA 02180

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



































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]