home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-pppext-funi-01.txt < prev    next >
Text File  |  1997-07-28  |  17KB  |  501 lines
  1.  
  2. PPP Extensions Working Group                       Manu Kaycee, Paradyne
  3. INTERNET DRAFT                         George Gross, Lucent Technologies
  4. Expires February 25, 1998                      Arthur Lin, Cisco Systems
  5.                                      Andrew Malis, Ascend Communications
  6.                                            John Stephens, Cayman Systems
  7.                                                            July 25, 1997
  8.  
  9.  
  10.                              PPP Over FUNI
  11.  
  12.                     <draft-ietf-pppext-funi-01.txt>
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19. Status Of This Memo
  20.  
  21. This document is an Internet-Draft.  Internet-Drafts are working
  22. documents of the Internet Engineering Task Force (IETF), its areas, and
  23. its working groups.  Note that other groups may also distribute working
  24. documents as Internet-Drafts.
  25.  
  26. Internet-Drafts are draft documents valid for a maximum of six months
  27. and may be updated, replaced, or obsoleted by other documents at any
  28. time.  It is inappropriate to use Internet-Drafts as reference material
  29. or to cite them other than as ``work in progress.''
  30.  
  31. To learn the current status of any Internet-Draft, please check the
  32. ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  33. Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  34. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  35. ftp.isi.edu (US West Coast).
  36.  
  37. Distribution of this memo is unlimited.
  38.  
  39. Abstract
  40.  
  41.      The Point-to-Point Protocol (PPP) [1] provides a standard method
  42.      for transporting multi-protocol datagrams over point-to-point
  43.      links.
  44.  
  45.      This document describes the use of ATM Frame User Network Interface
  46.      (FUNI)  for framing PPP encapsulated packets.
  47.  
  48. Applicability
  49.  
  50.  
  51. Gross, Kaycee, et al   Expires February 25th 1997       [Page 1]
  52.  
  53.  
  54. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  55.  
  56.  
  57. This specification is intended for those implementations which desire to
  58. use the facilities which are defined for PPP, such as the Link Control
  59. Protocol, Network-layer Control Protocols, authentication, and
  60. compression.  These capabilities require a point-to-point relationship
  61. between the peers, and are not designed for the multi-point
  62. relationships which are available in ATM and other multi-access
  63. environments.
  64.  
  65. 1. Introduction
  66.  
  67. ATM FUNI protocol is designed to provide virtual connections between end
  68. stations attached to the same network.  These connections offer a packet
  69. delivery service that includes error detection, but does not do error
  70. correction.
  71.  
  72. Most existing implementations of PPP use ISO 3309 HDLC as a basis for
  73. their framing [3].
  74.  
  75. When an ATM network is configured with point-to-point connections, PPP
  76. can use FUNI as a framing mechanism, ignoring its other features.
  77.  
  78. 2. FUNI Layer Service Interface
  79.  
  80. The PPP layer treats the underlying ATM FUNI layer service as a bit-
  81. synchronous point-to-point link.  In this context, the PPP link
  82. corresponds to an ATM FUNI virtual connection.  The virtual connection
  83. MUST be full-duplex, point to point, and it MAY be either dedicated
  84. (i.e. permanent, set up by provisioning) or switched (set up on demand).
  85. In addition, the PPP/FUNI service interface boundary MUST meet the
  86. following requirements:
  87.  
  88.      Interface Format - The PPP/FUNI layer boundary presents an octet
  89.      service interface to the FUNI layer.  There is no provision for
  90.      sub-octets to be supplied or accepted.
  91.  
  92.      Transmission Rate - The PPP layer does not impose any restrictions
  93.      regarding transmission rate.
  94.  
  95.      Control Signals - The FUNI layer must provide control signals to
  96.      the PPP layer which indicate when the virtual connection link has
  97.      become connected or disconnected.  These provide the "Up" and
  98.      "Down" events to the LCP state machine [1] within the PPP layer.
  99.  
  100. 3. Multi-Protocol Encapsulation
  101.  
  102. This specification uses the principles, terminology, and frame structure
  103. described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
  104. [4].
  105.  
  106.  
  107. Gross, Kaycee, et al   Expires February 25th 1997       [Page 2]
  108.  
  109.  
  110. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  111.  
  112.  
  113. The purpose of this specification is not to document what is already
  114. standardized in [4], but to specify how the mechanisms described in [4]
  115. are to be used to map PPP onto a FUNI-based  ATM network.  Section 1
  116. within [4] defines the two mechanisms for identifying the Protocol Data
  117. Unit (PDU) payload field's protocol type: virtual circuit based
  118. multiplexing, and Logical Link Control (LLC) encapsulation.  In the
  119. former technique, the payload's protocol type is implicitly agreed to by
  120. the end points for each virtual circuit using provisioning or control
  121. plane procedures.  When using the LLC encapsulation technique, the
  122. payload's protocol type is explicitly identified on a per PDU basis by
  123. an in-band LLC header, followed by the payload data.
  124.  
  125. When transporting a PPP payload over FUNI, an implementation:
  126.  
  127.      1. MUST support virtual circuit multiplexed PPP payloads as
  128.      described in section 4.  This technique is referred to as "VC-
  129.      multiplexed PPP".
  130.  
  131.      2.  MAY use LLC encapsulated PPP payloads on PVCs as described in
  132.      section 5 below by mutual configuration or negotiation of both end
  133.      points.  This technique is referred to as "LLC encapsulated PPP".
  134.  
  135.      3. If an implementation is connecting though a Frame Relay/ATM
  136.      FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point,
  137.      then it MUST support LLC encapsulated PPP payloads.
  138.  
  139.      4. For SVC set up, an implementation MUST negotiate using the
  140.      Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
  141.      Interface (B-LLI) information element to signal either VC-
  142.      multiplexed PPP or LLC encapsulated PPP.  The details of this
  143.      control plane procedure are described in section 6.
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163. Gross, Kaycee, et al   Expires February 25th 1997       [Page 3]
  164.  
  165.  
  166. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  167.  
  168.  
  169. 4. Virtual Circuit Multiplexed PPP Over FUNI
  170.  
  171.  
  172. The FUNI protocol data unit (PDU) format [2] is as follows:
  173.  
  174.                    +-------------------------------+
  175.                    |              Flag             |
  176.                    +-------------------------------+---------
  177.                    |           FUNI Header         |    ^
  178.                    +-------------------------------+    |
  179.                    |                               |    |
  180.                    |                               |    |
  181.                    |            User SDU           | FUNI PDU
  182.                    |                               |    |
  183.                    |                               |    |
  184.                    +-------------------------------+    |
  185.                    |   FUNI FCS (2 or 4 octets)    |    v
  186.                    +-------------------------------+---------
  187.                    |              Flag             |
  188.                    +-------------------------------+
  189.                                 Figure 1
  190.  
  191. The FUNI Header includes a 10-bit or 24-bit Frame Address (a.k.a.
  192. VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority
  193. bit, and four Reserved bits.
  194.  
  195. The User SDU field contains user information up to 4096 (optionally up
  196. to 64K) octets.
  197.  
  198. The FCS field protects the entire FUNI PDU except for the FCS field
  199. itself.
  200.  
  201. A VC-multiplexed PPP frame SHALL constitute the User Service Data Unit
  202. (SDU) field and is defined as shown in figure 2:
  203.  
  204.                   +----------+-------------+---------+
  205.                   | Protocol | Information | Padding |
  206.                   | 8/16 bits|             |         |
  207.                   +----------+-------------+---------+
  208.                                 Figure 2
  209.  
  210. Each of these fields are specifically defined in [1].
  211. Modification of the Basic FUNI Frame
  212.  
  213. The Link Control Protocol can negotiate modifications to the basic frame
  214. structure (e.g. AFC, etc).  However, any such modified frames MUST
  215. always be clearly distinguishable from standard frames.
  216.  
  217.  
  218.  
  219. Gross, Kaycee, et al   Expires February 25th 1997       [Page 4]
  220.  
  221.  
  222. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  223.  
  224.  
  225. 5. LLC Encapsulated PPP Over FUNI
  226.  
  227. LLC encapsulated PPP over FUNI is the alternative technique to VC-
  228. multiplexed PPP over FUNI.  LLC encapsulated PPP minimizes the ATM/Frame
  229. Relay inter-working translation complexity that occurs when a VCC is
  230. connected to an RFC 1973 compliant end point.
  231.  
  232.  
  233. The FUNI SDU payload  field is encoded as shown in figure 3:
  234.  
  235.           +-------------------------+ --------
  236.           |  Source SAP (0xFE)      |     ^
  237.           +-------------------------+     |
  238.           |  Destination SAP (0xFE) | LLC header
  239.           +-------------------------+     |
  240.           |  Frame Type = UI (0x03) |     V
  241.           +-------------------------+ --------
  242.           |  NLPID = PPP (0xCF)     |
  243.           +-------------------------+ --------
  244.           |  Protocol Identifier    |     ^
  245.           |     (8 or 16 bits)      |     |
  246.           +-------------------------+ PPP payload
  247.           |          .              |     |
  248.           |          .              |     |
  249.           |  PPP information field  |     |
  250.           |          .              |     |
  251.           |          .              |     V
  252.           +-------------------------+ --------
  253.  
  254.                                 Figure 3
  255.  
  256. The fields in the above diagram are:
  257.  
  258.      1. LLC header: 2 bytes encoded to specify a source SAP and
  259.      destination SAP of non-OSI routed PDU (values 0xFE 0xFE), followed
  260.      by an Un-numbered Information (UI) frame type (value 0x03).
  261.  
  262.      2. Network Layer Protocol IDentifier (NLPID) representing PPP,
  263.      (value 0xCF).
  264.  
  265.      3. the PPP protocol identifier field, which can be either 1 or 2
  266.      octets long.
  267.  
  268.      4. followed by the PPP information field.
  269.  
  270.  
  271. 6. Out-Of-Band Control Plane Signaling
  272.  
  273.  
  274.  
  275. Gross, Kaycee, et al   Expires February 25th 1997       [Page 5]
  276.  
  277.  
  278. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  279.  
  280.  
  281. When originating a switched virtual circuit FUNI connection, the caller
  282. MUST request in the SETUP message either one or else both of the RFC1483
  283. protocol encapsulation techniques for PPP payload transport.  When a
  284. caller is offering both techniques, the two BLLI IEs are encoded within
  285. a Broadband Repeat Indicator IE in the order of their preferance.  The
  286. called implementation MUST be able to accept an incoming call that
  287. offers VC-multiplexed PPP in the caller's request.  The called
  288. implementation MAY reject a call set up request that only offers LLC
  289. encapsulated PPP.  Implementations originating a call offering both
  290. protocol encapsulation techniques MUST be able to negotiate to the fall
  291. back position of VC-multiplexed PPP and still inter-operate.
  292.  
  293. When originating a virtual circuit multiplexed call that is to carry a
  294. PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3
  295. protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7.  The
  296. extension octets specify an IPI value of PPP (0xCF).  By definition, the
  297. first bytes of the FUNI frame's payload field will always contain a PPP
  298. header followed by a packet.
  299.  
  300. When originating an LLC encapsulated call that is to carry a PPP
  301. payload, the ITU Q.2931 B-LLI element user information layer 2 protocol
  302. field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in
  303. octet 6.  See RFC 1755 [8] appendix A for an example.  By definition,
  304. the first bytes of the FUNI frame's payload field will contain an LLC
  305. header, followed by a NLPID and the PPP payload.
  306.  
  307. 7. PPP Link Control Protocol Phase Transitions
  308.  
  309. Initial LCP packets contain the sequence cf-c0-21.
  310.  
  311. In the case of FUNI, they follow the FUNI Header.   When a LCP
  312. Configure-Request packet is received and recognized, the PPP link enters
  313. Link Establishment phase.
  314.  
  315. Configuration requests received over multi-point connections SHOULD
  316. result in (a) misconfiguration indication(s).  This can be detected by
  317. multiple responses to the LCP Configure-Request with the same
  318. Identifier, coming from different framing addresses.  Some
  319. implementations might be physically unable to either log or report such
  320. information.
  321.  
  322. Once PPP has entered the Network-layer Protocol phase, and successfully
  323. negotiated a particular NCP for a PPP Protocol, if a frame arrives using
  324. an alternate but equivalent data encapsulation defined in [4], the PPP
  325. Link MUST re-enter Link Establishment phase and send a new LCP
  326. Configure-Request.  This prevents "black-holes" that occur when the peer
  327. loses state.
  328.  
  329.  
  330.  
  331. Gross, Kaycee, et al   Expires February 25th 1997       [Page 6]
  332.  
  333.  
  334. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  335.  
  336.  
  337. An implementation which requires PPP link configuration, and other PPP
  338. negotiated features (such as authentication), MAY enter Termination
  339. phase when configuration fails.
  340.  
  341. 8. Configuration Options
  342.  
  343. The following Configuration Options are recommended:
  344.  
  345.          Magic Number
  346.  
  347.          Protocol Field Compression
  348.  
  349.  
  350. 9. Security Considerations
  351.  
  352. Generally, ATM networks are virtual circuit based, and security is
  353. implicit in the public data networking service provider's administration
  354. of Permanent Virtual Circuits (PVCs) between the network boundaries.
  355. The probability of a security breach caused by mis-routed ATM cells is
  356. considered to be negligible.
  357.  
  358. When a public ATM network supports Switched Virtual Circuits, the
  359. protocol model becomes analogous to traditional voice band modem dial up
  360. over the Public Telephone Switched Network (PTSN).  The same PAP/CHAP
  361. authentication protocols that are already widely in use for Internet
  362. dial up access are leveraged.  As a consequence, PPP over FUNI security
  363. is at parity with those practices already established by the existing
  364. Internet infrastructure.
  365.  
  366. Those applications that require stronger security are encouraged to use
  367. authentication headers, or encrypted payloads, and/or ATM-layer security
  368. services.
  369.  
  370.  
  371.  
  372. References
  373.  
  374. [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  375.       51, RFC 1661, July 1994.
  376.  
  377. [2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
  378.       Specification v2", af-saa-0088.000, May 1997.
  379.  
  380. [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
  381.       RFC 1662, July 1994.
  382.  
  383. [4]   Hienanan, J., "Multiprotocol Interconnect over AAL5",
  384.       RFC 1483, July 1993.
  385.  
  386.  
  387. Gross, Kaycee, et al   Expires February 25th 1997       [Page 7]
  388.  
  389.  
  390. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  391.  
  392.  
  393. [5]   ISO/IEC DTR 9577.2, "Information technology -
  394.       Telecommunications and Information exchange between systems -
  395.       Protocol Identification in the network layer", 1995-08-16.
  396.  
  397. [6]   Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
  398.  
  399. [7]   The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working
  400.       Implementation Agreement", FRF.8, April 1995.
  401.  
  402. [8]   M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis,
  403.       "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
  404.  
  405. [9]   International Telecommunication Union, "Broadband Integrated Service
  406.       Digital Network (B-ISDN) Digital Subscriber Signaling System No.2
  407.       (DSS2) User Network Interface Layer 3 Specification for Basic
  408.       Call/Connection Control", ITU-T Recommendation Q.2931, (International
  409.       Telecommunication Union: Geneva, 2/95)
  410.  
  411.  
  412. 10. Acknowledgments
  413.  
  414. This design is based on work performed in ADSL Forum's Packet Mode
  415. Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973, by
  416. William Simpson.
  417.  
  418. Chair's Address The working group can be contacted via the current
  419. chair:
  420.            Karl Fox
  421.            Ascend Communications
  422.            3518 Riverside Drive, Suite 101
  423.            Columbus, Ohio 43221
  424.  
  425.            EMail: karl@ascend.com
  426.  
  427.  
  428. Author's Address
  429.  
  430. Questions about this memo can also be directed to:
  431.  
  432.      Manu Kaycee
  433.      Paradyne Corporation
  434.      100 Shultz Drive
  435.      Red Bank, NJ 07701
  436.      Tel:   +1.732.345.7664
  437.      Email: mjk@nj.paradyne.com
  438.  
  439.      George Gross
  440.      Lucent Technologies, Inc
  441.  
  442.  
  443. Gross, Kaycee, et al   Expires February 25th 1997       [Page 8]
  444.  
  445.  
  446. Internet Draft             PPP Over ATM FUNI              July 25th 1997
  447.  
  448.  
  449.      184 Liberty Corner Road
  450.      Warren, NJ 07059
  451.      Tel:   +1.908.580.4589
  452.      Email: gmg@garage.lucent.com
  453.  
  454.      Arthur Lin
  455.      Cisco Systems, Inc.
  456.      170 West Tasman Drive
  457.      San Jose, CA 95134
  458.      Tel:   +1.408.526.8260
  459.      Email: alin@cisco.com
  460.  
  461.      Andrew Malis
  462.      Ascend Communications, Inc.
  463.      5 Carlisle Road
  464.      Westford, MA 01886
  465.      Tel:  +1.508.952.7414
  466.      Email: malis@casc.com
  467.  
  468.      John Stephens
  469.      Cayman Systems, Inc.
  470.      100 Maple Street
  471.      Stoneham, MA 02180
  472.      Tel:   +1.617.279.1101
  473.      Email: john@cayman.com
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499. Gross, Kaycee, et al   Expires February 25th 1997       [Page 9]
  500.  
  501.