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