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-02.txt < prev    next >
Text File  |  1997-09-30  |  21KB  |  557 lines
  1.  
  2. PPP Extensions Working Group           George Gross, Lucent Technologies
  3. INTERNET DRAFT                                     Manu Kaycee, Paradyne
  4. Expires April 15, 1998                         Arthur Lin, Cisco Systems
  5.                                      Andrew Malis, Ascend Communications
  6.                                            John Stephens, Cayman Systems
  7.                                                       September 29, 1997
  8.  
  9.  
  10.                              PPP Over AAL5
  11.  
  12.                     <draft-ietf-pppext-aal5-02.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 Adaptation Layer 5 (AAL5)
  46.      for framing PPP encapsulated packets.
  47.  
  48. Applicability
  49.  
  50.  
  51. Gross, Kaycee, et al    Expires April 29th 1997         [Page 1]
  52.  
  53.  
  54. Internet Draft             PPP Over ATM AAL5         September 29th 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 AAL5 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 AAL5 as a framing mechanism.
  77.  
  78. 2. Specification of Requirements
  79.  
  80. In this document, several words are used to signify the requirements of
  81. the specification.  These words are often capitalized.
  82.  
  83.      MUST - This word, or the adjective "required", means that the
  84.      definition is an absolute requirement of the specification.
  85.  
  86.      MUST NOT - This phrase means that the definition is an absolute
  87.      prohibition of the specification.
  88.  
  89.      SHOULD - This word, or the adjective "recommended", means that
  90.      there may exist valid reasons in particular circumstances to ignore
  91.      this item, but the full implications MUST be understood and
  92.      carefully weighed before choosing a different course.
  93.  
  94.      MAY - This word, or the adjective "optional", means that this item
  95.      is one of an allowed set of alternatives.  An implementation which
  96.      does not include this option MUST be prepared to interoperate with
  97.      another implementation which does include the option.
  98.  
  99.  
  100. 3. AAL5 Layer Service Interface
  101.  
  102. The PPP layer treats the underlying ATM AAL5 layer service as a bit-
  103. synchronous point-to-point link.  In this context, the PPP link
  104. corresponds to an ATM AAL5 virtual connection.  The virtual connection
  105.  
  106.  
  107. Gross, Kaycee, et al    Expires April 29th 1997         [Page 2]
  108.  
  109.  
  110. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  111.  
  112.  
  113. MUST be full-duplex, point to point, and it MAY be either dedicated
  114. (i.e. permanent, set up by provisioning) or switched (set up on demand).
  115. In addition, the PPP/AAL5 service interface boundary MUST meet the
  116. following requirements:
  117.  
  118.      Interface Format - The PPP/AAL5 layer boundary presents an octet
  119.      service interface to the AAL5 layer.  There is no provision for
  120.      sub-octets to be supplied or accepted.
  121.  
  122.      Transmission Rate - The PPP layer does not impose any restrictions
  123.      regarding transmission rate.
  124.  
  125.      Control Signals - The AAL5 layer must provide control signals to
  126.      the PPP layer which indicate when the virtual connection link has
  127.      become connected or disconnected.  These provide the "Up" and
  128.      "Down" events to the LCP state machine [1] within the PPP layer.
  129.  
  130. 4. Multi-Protocol Encapsulation
  131.  
  132. This specification uses the principles, terminology, and frame structure
  133. described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
  134. [4].
  135.  
  136. The purpose of this specification is not to document what is already
  137. standardized in [4], but to specify how the mechanisms described in [4]
  138. are to be used to map PPP onto an AAL5-based  ATM network.  Section 1
  139. within [4] defines the two mechanisms for identifying the Protocol Data
  140. Unit (PDU) payload field's protocol type: virtual circuit based
  141. multiplexing, and Logical Link Control (LLC) encapsulation.  In the
  142. former technique, the payload's protocol type is implicitly agreed to by
  143. the end points for each virtual circuit using provisioning or control
  144. plane procedures.  When using the LLC encapsulation technique, the
  145. payload's protocol type is explicitly identified on a per PDU basis by
  146. an in-band LLC header, followed by the payload data.
  147.  
  148. When transporting a PPP payload over AAL5, an implementation:
  149.  
  150.      1. MUST support virtual circuit multiplexed PPP payloads as
  151.      described in section 5.  This technique is referred to as "VC-
  152.      multiplexed PPP".
  153.  
  154.      2.  MAY use LLC encapsulated PPP payloads on PVCs as described in
  155.      section 6 below by mutual configuration or negotiation of both end
  156.      points.  This technique is referred to as "LLC encapsulated PPP".
  157.  
  158.      3. If an implementation is connecting though a Frame Relay/ATM
  159.      FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point,
  160.      then it MUST support LLC encapsulated PPP payloads.
  161.  
  162.  
  163. Gross, Kaycee, et al    Expires April 29th 1997         [Page 3]
  164.  
  165.  
  166. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  167.  
  168.  
  169.      4. For SVC set up, an implementation MUST negotiate using the
  170.      Q.2931 [9] Annex C procedure, encoding the Broadband Lower Layer
  171.      Interface (B-LLI) information element to signal either VC-
  172.      multiplexed PPP or LLC encapsulated PPP.  The details of this
  173.      control plane procedure are described in section 7.
  174.  
  175. 5. Virtual Circuit Multiplexed PPP Over AAL5
  176.  
  177.  
  178. The AAL5 PDU format is shown in figure 1:
  179.  
  180.                      AAL5 CPCS-PDU Format
  181.                +-------------------------------+
  182.                |             .                 |
  183.                |             .                 |
  184.                |        CPCS-PDU Payload       |
  185.                |     up to 2^16 - 1 octets)    |
  186.                |             .                 |
  187.                |             .                 |
  188.                +-------------------------------+
  189.                |      PAD ( 0 - 47 octets)     |
  190.                +-------------------------------+ -------
  191.                |       CPCS-UU (1 octet )      |
  192.                +-------------------------------+
  193.                |         CPI (1 octet )        |
  194.                +-------------------------------+CPCS-PDU Trailer
  195.                |        Length (2 octets)      |
  196.                +-------------------------------|
  197.                |         CRC (4 octets)        |
  198.                +-------------------------------+ -------
  199.                                 Figure 1
  200.  
  201. The Common Part Convergence Sub-layer (CPCS)-PDU Payload field contains
  202. user information up to 2^16 - 1 octets.
  203.  
  204. The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such
  205. that the last 48 octet cell payload created by the SAR sublayer will
  206. have the CPCS-PDU Trailer right justified in the cell.
  207.  
  208. The CPCS-UU (User-to-User indication) field is used to transparently
  209. transfer CPCS user to user information.  The field has no function under
  210. the multi-protocol ATM encapsulation described in this memo and can be
  211. set to any value.
  212.  
  213. The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64
  214. bits.  Possible additional functions are for further study in ITU-T.
  215. When only the 64 bit alignment function is used, this field shall be
  216. coded as 0x00.
  217.  
  218.  
  219. Gross, Kaycee, et al    Expires April 29th 1997         [Page 4]
  220.  
  221.  
  222. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  223.  
  224.  
  225. The Length field indicates the length, in octets, of the Payload field.
  226. The maximum value for the Length field is 65535 octets.  A Length field
  227. coded as 0x00 is used for the abort function.
  228.  
  229. The CRC field protects the entire CPCS-PDU except the CRC field itself.
  230.  
  231. A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and is
  232. defined as:
  233.  
  234.                +-------------+-------------+---------+
  235.                | Protocol ID | Information | Padding |
  236.                |  8/16 bits  |             |         |
  237.                +-------------+-------------+---------+
  238.                                 Figure 2
  239.  
  240. Each of these fields are specifically defined in [1].
  241.  
  242. 6. LLC Encapsulated PPP Over AAL5
  243.  
  244. LLC encapsulated PPP over AAL5 is the alternative technique to VC-
  245. multiplexed PPP over AAL5.  LLC encapsulated PPP minimizes the ATM/Frame
  246. Relay inter-working translation complexity that occurs when a VCC is
  247. connected to an RFC 1973 compliant end point.
  248.  
  249.  
  250. The AAL5 CPCS-PDU payload  field is encoded as shown in figure 3:
  251.  
  252.           +-------------------------+ --------
  253.           |  Destination SAP (0xFE) |     ^
  254.           +-------------------------+     |
  255.           |  Source SAP (0xFE)      | LLC header
  256.           +-------------------------+     |
  257.           |  Frame Type = UI (0x03) |     V
  258.           +-------------------------+ --------
  259.           |  NLPID = PPP (0xCF)     |
  260.           +-------------------------+ --------
  261.           |   Protocol Identifier   |     ^
  262.           |     (8 or 16 bits)      |     |
  263.           +-------------------------+ PPP payload
  264.           |          .              |     |
  265.           |          .              |     |
  266.           |  PPP information field  |     |
  267.           |          .              |     |
  268.           |          .              |     V
  269.           +-------------------------+ --------
  270.  
  271.                                 Figure 3
  272.  
  273.  
  274.  
  275. Gross, Kaycee, et al    Expires April 29th 1997         [Page 5]
  276.  
  277.  
  278. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  279.  
  280.  
  281. The fields in the above diagram are:
  282.  
  283.      1. LLC header: 2 bytes encoded to specify a source SAP and
  284.      destination SAP of routed OSI PDU (values 0xFE 0xFE), followed by
  285.      an Un-numbered Information (UI) frame type (value 0x03).
  286.  
  287.      2. Network Layer Protocol IDentifier (NLPID) representing PPP,
  288.      (value 0xCF).
  289.  
  290.      3. the PPP protocol identifier field, which can be either 1 or 2
  291.      octets long.
  292.  
  293.      4. followed by the PPP information field.
  294.  
  295. The end points MAY be bi-laterally provisioned to send other LLC-
  296. encapsulated protocols besides PPP across the same virtual connection.
  297. However, they MUST NOT send packets belonging to any protocol that has
  298. an active NCP within the PPP session.  Implementations SHOULD do packet
  299. scheduling that minimizes the performance impact on the quality of
  300. service commitments associated with both the LLC-encapsulated PPP and
  301. non-PPP protocol flows.
  302.  
  303. 7. Out-Of-Band Control Plane Signaling
  304.  
  305. When originating a switched virtual circuit AAL5 connection, the caller
  306. MUST request in the SETUP message either VC-multiplexed PPP, LLC-
  307. encapsulated PPP, or else both VC-multiplexed and LLC-encapsulated PPP.
  308. Note that to guarantee inter-operability, it is suggested that VC-
  309. multiplexed PPP always be requested.  When a caller is offering both
  310. techniques, the two BLLI IEs are encoded within a Broadband Repeat
  311. Indicator IE in the order of their preferance.  The called
  312. implementation MUST be able to accept an incoming call that offers VC-
  313. multiplexed PPP in the caller's request.  The called implementation MAY
  314. reject a call set up request that only offers LLC encapsulated PPP.
  315. Implementations originating a call offering both protocol encapsulation
  316. techniques MUST be able to negotiate the use of VC-multiplexed PPP.
  317.  
  318. When originating a virtual circuit multiplexed call that is to carry a
  319. PPP payload, the ITU Q.2931 [9] B-LLI element user information layer 3
  320. protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7.  The
  321. extension octets specify an IPI value of PPP (0xCF).  By definition, the
  322. first bytes of the AAL5 frame's payload field will always contain a PPP
  323. header followed by a packet.
  324.  
  325. When originating an LLC encapsulated call that is to carry a PPP
  326. payload, the ITU Q.2931 B-LLI element user information layer 2 protocol
  327. field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in
  328. octet 6.  See RFC 1755 [8] appendix A for an example.  By definition,
  329.  
  330.  
  331. Gross, Kaycee, et al    Expires April 29th 1997         [Page 6]
  332.  
  333.  
  334. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  335.  
  336.  
  337. the first bytes of the AAL5 frame's payload field will contain an LLC
  338. header, followed by a NLPID and the PPP payload.
  339.  
  340. 8. Detection And Recovery From Unsolicited PPP Encapsulation Transitions
  341.  
  342. When the virtual connection loses state, the PPP encapsulation technique
  343. may uni-laterally and unexpectedly change across such transitions.
  344. Detection and recovery procedures are defined for the following state
  345. transitions:
  346.  
  347.      VC-multiplexed PPP changing to LLC encapsulated PPP
  348.  
  349.      LLC encapsulated PPP changing to VC-multiplexed PPP
  350.  
  351. When LLC-encapsulated PPP is being used, the inital 6 octets of the LCP
  352. packets contain the sequence: fe-fe-03-cf-c0-21.  This sequence
  353. constitutes the first 6 octets of the AAL5 frame.  In the case of VC-
  354. multiplexed PPP, initial LCP packets contain the sequence c0-21.  This
  355. sequence constitutes the first 2 octets of an AAL5 frame.   When a LCP
  356. Configure-Request packet is received and recognized, the PPP link enters
  357. Link Establishment phase.
  358.  
  359. Configuration requests received over multi-point connections SHOULD
  360. result in (a) misconfiguration indication(s).  This can be detected by
  361. multiple responses to the LCP Configure-Request with the same
  362. Identifier, coming from different framing addresses.  Some
  363. implementations might be physically unable to either log or report such
  364. information.
  365.  
  366. Once PPP has entered the Network-layer Protocol phase, and successfully
  367. negotiated a particular NCP for a PPP Protocol, if a frame arrives using
  368. an alternate but equivalent data encapsulation defined in [4], the PPP
  369. Link MUST re-enter Link Establishment phase and send a new LCP
  370. Configure-Request.  This prevents "black-holes" that occur when the peer
  371. loses state.
  372.  
  373. An implementation which requires PPP link configuration, and other PPP
  374. negotiated features (such as authentication), MAY enter Termination
  375. phase when configuration fails.
  376.  
  377. 9. LCP Configuration Options
  378.  
  379. The Magic Number LCP configuration option is recommended, and the
  380. Protocol Field Compression (PFC) option is not recommended.  An
  381. implementation MUST NOT request any of the following options, and MUST
  382. reject a request for such an option:
  383.  
  384.      Field Check Sequence (FCS) Alternatives,
  385.  
  386.  
  387. Gross, Kaycee, et al    Expires April 29th 1997         [Page 7]
  388.  
  389.  
  390. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  391.  
  392.  
  393.      Address-and-Control-Field-Compression (ACFC),
  394.  
  395.  
  396. The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger
  397. size than the maximum CPCS-SDU size specified in the associated
  398. direction for the virtual connection's traffic contract.
  399.  
  400. PPP over AAL5 to octet-oriented asynchronous PPP conversion is handled
  401. in the same way as the octet-oriented asynchronous to bit-synchronous
  402. conversion described in [3] section 6.  The PPP over AAL5
  403. implementation MUST alway respond to the Asynchronous-Control-
  404. Character-Map (ACCM) configuration option with the LCP Configure-Ack.
  405. However, acceptance of the Configuration Option does not imply that the
  406. PPP over AAL5 implementation will do any ACCM mapping.  Instead, all
  407. such octet mapping will be performed by the PPP over AAL5 to octet-
  408. oriented asynchronous PPP convertor.
  409.  
  410. 10. Security Considerations
  411.  
  412. Generally, ATM networks are virtual circuit based, and security is
  413. implicit in the public data networking service provider's administration
  414. of Permanent Virtual Circuits (PVCs) between the network boundaries.
  415. The probability of a security breach caused by mis-routed ATM cells is
  416. considered to be negligible.
  417.  
  418. When a public ATM network supports Switched Virtual Circuits, the
  419. protocol model becomes analogous to traditional voice band modem dial up
  420. over the Public Telephone Switched Network (PTSN).  The same PAP/CHAP
  421. authentication protocols that are already widely in use for Internet
  422. dial up access are leveraged.  As a consequence, PPP over AAL5 security
  423. is at parity with those practices already established by the existing
  424. Internet infrastructure.
  425.  
  426. Those applications that require stronger security are encouraged to use
  427. authentication headers, or encrypted payloads, and/or ATM-layer security
  428. services.
  429.  
  430. When using LLC-encapsulated PPP over a virtual connection, an end point
  431. can not assume that the PPP session authentication and related security
  432. mechanisms also secure the other LLC encapsulated flows on that same
  433. virtual connection.
  434.  
  435.  
  436.  
  437. References
  438.  
  439. [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  440.       51, RFC 1661, July 1994.
  441.  
  442.  
  443. Gross, Kaycee, et al    Expires April 29th 1997         [Page 8]
  444.  
  445.  
  446. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  447.  
  448.  
  449. [2]   The ATM Forum, "Frame based User-to-Network Interface (FUNI)
  450.       Specification v2", af-saa-0088.000, May 1997.
  451.  
  452. [3]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
  453.       RFC 1662, July 1994.
  454.  
  455. [4]   Hienanan, J., "Multiprotocol Interconnect over AAL5",
  456.       RFC 1483, July 1993.
  457.  
  458. [5]   ISO/IEC DTR 9577.2, "Information technology -
  459.       Telecommunications and Information exchange between systems -
  460.       Protocol Identification in the network layer", 1995-08-16.
  461.  
  462. [6]   Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
  463.  
  464. [7]   The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working
  465.       Implementation Agreement", FRF.8, April 1995.
  466.  
  467. [8]   M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis,
  468.       "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
  469.  
  470. [9]   International Telecommunication Union, "Broadband Integrated Service
  471.       Digital Network (B-ISDN) Digital Subscriber Signaling System No.2
  472.       (DSS2) User Network Interface Layer 3 Specification for Basic
  473.       Call/Connection Control", ITU-T Recommendation Q.2931, (International
  474.       Telecommunication Union: Geneva, 2/95)
  475.  
  476.  
  477. 11. Acknowledgments
  478.  
  479. This design is based on work performed in ADSL Forum's Packet Mode
  480. Working Group.  It is inspired by  "PPP in Frame Relay", RFC 1973, by
  481. William Simpson.  Special thanks to Phil Rakity of Flowpoint, Tim Kwok
  482. of Microsoft, and David Allan of Nortel for their constructive review
  483. and commentary.
  484.  
  485. Chair's Address The working group can be contacted via the current
  486. chair:
  487.            Karl Fox
  488.            Ascend Communications
  489.            3518 Riverside Drive, Suite 101
  490.            Columbus, Ohio 43221
  491.  
  492.            EMail: karl@ascend.com
  493.  
  494.  
  495. Author's Address
  496.  
  497.  
  498.  
  499. Gross, Kaycee, et al    Expires April 29th 1997         [Page 9]
  500.  
  501.  
  502. Internet Draft             PPP Over ATM AAL5         September 29th 1997
  503.  
  504.  
  505. Questions about this memo can also be directed to:
  506.  
  507.      George Gross
  508.      Lucent Technologies, Inc
  509.      184 Liberty Corner Road
  510.      Warren, NJ 07059
  511.      Tel:   +1.908.580.4589
  512.      Email: gmgross@lucent.com
  513.  
  514.      Manu Kaycee
  515.      Paradyne Corporation
  516.      100 Shultz Drive
  517.      Red Bank, NJ 07701
  518.      Tel:   +1.732.345.7664
  519.      Email: mjk@nj.paradyne.com
  520.  
  521.      Arthur Lin
  522.      Cisco Systems, Inc.
  523.      170 West Tasman Drive
  524.      San Jose, CA 95134
  525.      Tel:   +1.408.526.8260
  526.      Email: alin@cisco.com
  527.  
  528.      Andrew Malis
  529.      Ascend Communications, Inc.
  530.      5 Carlisle Road
  531.      Westford, MA 01886
  532.      Tel:  +1.508.952.7414
  533.      Email: malis@casc.com
  534.  
  535.      John Stephens
  536.      Cayman Systems, Inc.
  537.      100 Maple Street
  538.      Stoneham, MA 02180
  539.      Tel:   +1.617.279.1101
  540.      Email: john@cayman.com
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555. Gross, Kaycee, et al    Expires April 29th 1997        [Page 10]
  556.  
  557.