idnits 2.17.1 draft-ietf-pppext-l2tp-atm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 6) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '14' is defined on line 476, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 479, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1483 (ref. '7') (Obsoleted by RFC 2684) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 1334 (ref. '12') (Obsoleted by RFC 1994) ** Obsolete normative reference: RFC 1969 (ref. '15') (Obsoleted by RFC 2419) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Extensions Working Group Mike Davison, Cisco 2 INTERNET DRAFT Mark Jeffrey, Microsoft 3 August, 1998 Arthur Lin, Shasta Networks 4 Expires January 31, 1999 Ajoy Singh, 3Com 5 John Stephens, Cayman Systems 6 Rollins Turner, Paradyne (editor) 8 L2TP Over AAL5 and FUNI 10 12 Status Of This Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute working 17 documents as Internet-Drafts 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 27 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 28 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Distribution of this memo is unlimited. 32 Abstract 34 The Layer Two Tunneling Protocol (L2TP) [1] provides a standard 35 method for transporting the link layer of PPP [2] between a dial-up 36 server and a Network Access Server, using a network connection in 37 lieu of a physical point to point connection. This document 38 describes the use of an ATM network for the underlying network 39 connection. Both ATM UNI [3] with ATM Adaptation Layer 5 [4] 40 (AAL5) and ATM with Frame based User-to-Network Interface (FUNI) 41 [5] are supported as interfaces to the ATM network. 43 Applicability 45 This specification is intended for implementations of L2TP that use ATM 46 to provide the communications link between the L2TP Access Concentrator 47 and the L2TP Network Server. 49 1. Introduction 51 The Point-to-Point Protocol, PPP, [2] is frequently used on the link 52 between a personal computer with a dial modem and a network service 53 provider, or NSP. The Layer Two Tunneling Protocol (L2TP) [1] enables a 54 dial-up server to provide access to a remote NSP by extending the PPP 55 connection through a tunnel in a network to which both it and the NSP 56 are directly connected. A "tunnel" is a network layer connection 57 between two nodes, used in the role of a data link layer connection 58 between those nodes, possibly as part of a different network. 60 In [1] the dial-up server is called an L2TP Access Concentrator, or LAC. 61 The remote device that provides access to a network is called an L2TP 62 Network Server, or LNS. L2TP uses a packet delivery service to create a 63 tunnel between the LAC and the LNS. "L2TP is designed to be largely 64 insulated from the details of the media over which the tunnel is 65 established; L2TP requires only that the tunnel media provide packet 66 oriented point-to-point connectivity" [1]. An ATM network, with either 67 AAL5 or FUNI, offers a suitable form of packet oriented connection. 69 This standard supplements [1] by providing details specific to the use 70 of AAL5 and FUNI for the point-to-point connection between LAC and LNS. 72 2. Conventions 74 2.1 Requirements Keywords 76 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 77 NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, 78 are to be interpreted as described in [6]. 80 2.2 Terminology 82 A list of acronyms used in this document is given at the end of the 83 document as Appendix A. 85 3. AAL5 Layer Service Interface 87 L2TP treats the underlying ATM AAL5 layer service as a bit-synchronous 88 point-to-point link. In this context, the L2TP link corresponds to an 89 ATM AAL5 virtual circuit (VC.) The VC MUST be full-duplex, point to 90 point, and it MAY be either dedicated (i.e., permanent, set up by 91 provisioning) or switched (set up on demand.) 93 Interface Format - The L2TP/AAL5 layer boundary presents an octet 94 service interface to the AAL5 layer. There is no provision for sub- 95 octets to be supplied or accepted. 97 3.1 Maximum Transfer Unit 99 Each L2TP PDU MUST be transported within a single AAL5 PDU. Therefore 100 the maximum transfer unit (MTU) of the AAL5 connection constrains the 101 MTU of the L2TP tunnel that uses the connection and the MTU of all PPP 102 connections that use the tunnel. (PPP refers to this as Maximum Receive 103 Unit, or MRU [2]. In the UNI 3.1 specification it is Forward and 104 Backward Maximum CPCS-SDU Size [3].) 106 An implementation MUST support a PPP MRU of at least 1500 bytes. 108 An implementation SHOULD use a larger MTU than the minimum value 109 specified above. A value of TBD is RECOMMENDED. 111 3.2 Quality of Service 113 In order to provide a desired quality of service, and possibly different 114 qualities of service to different client connections, an implementation 115 MAY use more than one AAL5 connection between LAC and LNS. 117 A tunnel is initially created over an AAL5 connection. A subsequent 118 call to the LAC may require that the LAC open a new AAL5 connection to 119 satisfy QoS requirements of that call. If an implementation determines 120 that multiple tunnels are required to a given peer, each tunnel SHALL be 121 based on a separate AAL5 connection. 123 3.3 ATM Connection Parameters 125 The L2TP layer does not impose any restrictions regarding transmission 126 rate or the underlying ATM layer traffic descriptor parameters. 128 Specific traffic parameters MAY be set for a PVC connection by agreement 129 between the communicating parties. The caller MAY request specific 130 traffic parameters at the time an SVC connection is set up. 132 4. Multi-Protocol Encapsulation 134 This specification uses the principles, terminology, and frame structure 135 described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" 136 [7] (RFC 1483.) The purpose of this specification is not to reiterate 137 what is already standardized in [7], but to specify how the mechanisms 138 described in [7] are to be used to map L2TP onto an AAL5-based ATM 139 network. 141 As specified in [7], L2TP PDUs shall be carried in the Payload field of 142 Common Part Convergence Sublayer (CPCS) PDUs of ATM Adaptation Layer 143 type 5 (AAL5), and the Service Specific Convergence Sublayer (SSCS) of 144 AAL5 shall be empty. 146 Section 1 of [7] defines two mechanisms for identifying the protocol 147 encapsulated in the AAL5 PDU's payload field: 149 1. Virtual circuit (VC) based multiplexing. 150 2. Logical Link Control (LLC) encapsulation. 152 In the first mechanism, the payload's protocol type is implicitly agreed 153 to by the end points for each virtual circuit using provisioning or 154 control plane procedures. This mechanism will be referred to as "VC- 155 multiplexed L2TP". 157 In the second mechanism, the payload's protocol type is explicitly 158 identified in each AAL5 PDU by an IEEE 802.2 LLC header. This mechanism 159 will be referred to as "LLC encapsulated L2TP". 161 An L2TP implementation: 163 1. MUST support LLC encapsulated L2TP on PVCs. 165 2. MAY support LLC encapsulated L2TP on SVCs. 167 3. MAY support VC-multiplexed L2TP on PVCs or SVCs. 169 When a PVC is used, the endpoints must be configured to use one of the 170 two encapsulation methods. 172 If an implementation supports switched VC connections, it MUST use the 173 Q.2931 [8] Annex C procedure to negotiate connection setup, encoding the 174 Broadband Lower Layer Interface (B-LLI) information element to signal 175 either VC-multiplexed L2TP or LLC encapsulated L2TP. The details of 176 this control plane procedure are described in section 7. 178 If an implementation is connecting through a Frame Relay/ATM FRF.8 [9] 179 service inter-working unit, then it MUST use LLC encapsulated L2TP. 181 5. LLC Encapsulated L2TP Over AAL5 183 When LLC encapsulation is used, the Payload field of the AAL5 CPCS PDU 184 SHALL be encoded as shown in figure 1. The pertinent fields in that 185 diagram are: 187 1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA 188 followed by a frame type of Un-numbered Information (value 0x03). 189 This LLC header indicates that an IEEE 802.1a SNAP header follows 190 [7]. 192 2. IEEE 802.1a SNAP Header: The three octet Organizationally 193 Unique Identifier (OUI) value of 0x00-00-03 identifies IANA 194 (Internet Assigned Numbers Authority.) The two octet Protocol 195 Identifier (PID) identifies L2TP as the encapsulated protocol. The 196 PID value is to be determined by IANA. 198 3. The L2TP PDU. 200 +-------------------------+ -------- 201 | Destination SAP (0xAA) | ^ 202 +-------------------------+ | 203 | Source SAP (0xAA) | LLC header 204 +-------------------------+ | 205 | Frame Type = UI (0x03) | V 206 +-------------------------+ -------- 207 | OUI (0x00-00-5E)| | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header 209 | PID (2 octets) | | 210 +-------------------------+ -------- 211 | | ^ 212 | | | 213 | | L2TP PDU 214 | | | 215 | | | 216 | | V 217 +-------------------------+ -------- 219 Figure 1. 221 Note: The format of the overall AAL5 CPCS PDU is shown in the next 222 section. 224 The end points MAY be bi-laterally provisioned to send other LLC- 225 encapsulated protocols besides L2TP across the same virtual connection. 226 However, they MUST NOT send packets belonging to any protocol that has 227 an active NCP within a PPP session carried by the L2TP tunnel. 229 6. Virtual Circuit Multiplexed L2TP Over AAL5 231 VC-multiplexed L2TP over AAL5 is an alternative technique to LLC 232 encapsulated L2TP over AAL5 when both LAC and LNS use AAL5 as opposed to 233 FUNI. In this case the L2TP PDU is the AAL5 Payload. This is sometimes 234 called "Null encapsulation." 236 The AAL5 CPCS PDU format is shown in figure 2. 238 AAL5 CPCS-PDU Format 240 +-------------------------------+ ------- 241 | . | ^ 242 | . | | 243 | CPCS-PDU Payload | L2TP PDU 244 | up to 2^16 - 1 octets) | | 245 | . | V 246 +-------------------------------+ ------- 247 | PAD ( 0 - 47 octets) | 248 +-------------------------------+ ------- 249 | CPCS-UU (1 octet ) | ^ 250 +-------------------------------+ | 251 | CPI (1 octet ) | | 252 +-------------------------------+CPCS-PDU Trailer 253 | Length (2 octets) | | 254 +-------------------------------| | 255 | CRC (4 octets) | V 256 +-------------------------------+ ------- 258 Figure 2. 260 The Common Part Convergence Sub-layer (CPCS) PDU Payload field contains 261 user information up to 2^16 - 1 octets. 263 The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such 264 that the last 48 octet cell payload created by the SAR sublayer will 265 have the CPCS-PDU Trailer right justified in the cell. 267 The CPCS-UU (User-to-User indication) field is used to transparently 268 transfer CPCS user to user information. The field has no function under 269 the multi-protocol ATM encapsulation and MAY be set to any value. 271 The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 272 bits. Possible additional functions are for further study in ITU-T. 273 When only the 64 bit alignment function is used, this field SHALL be 274 coded as 0x00. 276 The Length field indicates the length, in octets, of the Payload field. 277 The maximum value for the Length field is 65535 octets. A Length field 278 coded as 0x00 MAY be used for the abort function. 280 The CRC field SHALL be computed over the entire CPCS-PDU except the CRC 281 field itself. 283 The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in [1]. 285 7. Out-Of-Band Control Plane Signaling 287 7.1 Connection Setup 289 A switched VC connection can originate at either the LAC or the LNS. An 290 implementation that supports the use of SVCs MUST be able to both 291 originate and respond to SVC setup requests. 293 When originating a switched virtual circuit AAL5 connection, the caller 294 MUST request in the SETUP message either VC-multiplexed L2TP, LLC 295 encapsulated L2TP, or else both VC-multiplexed and LLC-encapsulated 296 L2TP. The Broadband Low Layer Information (B-LLI) information element 297 SHALL be used to specify the requested encapsulation method. When a 298 caller is offering both techniques, the two B-LLI information elements 299 SHALL be encoded within a Broadband Repeat Indicator information element 300 in the order of the sender's preference. 302 An implementation MUST be able to accept an incoming call that offers 303 LLC encapsulated L2TP in the caller's request. The called 304 implementation MUST reject a call set up request that only offers an 305 encapsulation that it does not support. Implementations originating a 306 call offering both protocol encapsulation techniques MUST be able to 307 accept the use of either encapsulation technique. 309 When originating an LLC encapsulated call that is to carry an L2TP 310 payload, the ITU Q.2931 [8] B-LLI element user information layer 2 311 protocol field SHALL be encoded to select LAN Logical Link Control 312 (ISO/IEC8802-2) in octet 6. See RFC 1755 [11] appendix A for an 313 example. 315 When originating a VC-multiplexed call that is to carry an L2TP payload, 316 the ITU Q.2931 [8] B-LLI element user information layer 3 protocol field 317 SHALL be encoded to select ISO/IEC TR 9577 [10] in octet 7. The 318 extension octets specify an IPI value of L2TP (TBD). The AAL5 frame's 319 payload field will always contain an L2TP PDU. 321 If the caller offers both encapsulation methods and the called peer 322 accepts the call, the called peer SHALL specify the encapsulation method 323 by including exactly one B-LLI IE in the Connect message. 325 If an SVC tunnel is reset in accordance with section 4.1 of [1], both 326 ends MUST clear the connection. Any user sessions on the tunnel will be 327 terminated by the reset. Either end MAY attempt to re-establish the 328 tunnel upon receipt of a new request from a client. 330 7.2 Connection Setup Failure 332 When a connection setup fails, the L2TP entity that attempted the 333 connection setup MAY consider the called entity unreachable until 334 notified that the unreachable entity is available. The conditions under 335 which an entity determines that another is unreachable and how it 336 determines that the other is available again are implementation 337 decisions. 339 7.3 Connection Teardown 341 When there are no active sessions on an SVC tunnel, either end MAY 342 optionally clear the connection. 344 [Note: There is a race condition when one end starts to clear the 345 connection at the same time the other end starts to establish a new 346 session. Further work is needed here.] 348 8. Detection And Recovery From Unsolicited L2TP Encapsulation 349 Transitions 351 When the virtual connection loses state, the L2TP encapsulation 352 technique may unilaterally and unexpectedly change across such 353 transitions. Detection and recovery procedures are defined for the 354 following state transitions: 356 VC-multiplexed L2TP changing to LLC encapsulated L2TP 358 LLC encapsulated L2TP changing to VC-multiplexed L2TP 360 When LLC-encapsulated L2TP is being used, the initial 6 octets of the 361 L2TP PDUs contain the sequence: AA-AA-03-00-00-5E. This sequence 362 constitutes the first 6 octets of the AAL5 CPCS PDU. [Need a simple 363 way to identify VC-multiplexed L2TP PDUs.] 365 Once the L2TP control connection has entered the Established state, if a 366 frame arrives using an alternate but equivalent data encapsulation as 367 defined in [7], then the L2TP implementation MUST tear down the tunnel, 368 performing the actions specified in [1] for the event "Receive StopCCN." 369 If the AAL5 connection is an SVC, the implementation MUST terminate 370 the AAL5 connection with the cause value 111, "protocol error, 371 unspecified". 373 These policies prevent "black-holes" that can occur when the peer loses 374 state. 376 9. Connection Failure 378 Upon notification that an AAL5 SVC connection has been cleared, an 379 implementation SHALL tear down the tunnel and return the control 380 connection to the Idle state. 382 If an AAL5 PVC enters the "Stopped" state, an implementation SHALL tear 383 down the tunnel and return the control connection to the Idle state. 385 10. Security Considerations 387 ATM networks, being virtual circuit based, are generally less vulnerable 388 to security attacks than IP based networks. The probability of a 389 security breach caused by misrouted ATM cells is considered to be 390 negligible. 392 The L2TP base protocol provides a mechanism for tunnel authentication 393 during the Establishment phase. This authentication has the same 394 security attributes as CHAP [12, 13], and provides reasonable protection 395 against replay attacks. 397 Since L2TP encapsulates a PPP payload, the same PAP/CHAP authentication 398 protocols that are widely used for Internet dial up access can be used 399 at both LAC and LNS to authenticate tunnel users. PPP encryption [14, 400 15] 401 can also be used to encrypt the PPP payload through L2TP. As a 402 consequence, 403 L2TP Over AAL5 security is at parity with those practices already 404 established by the existing Internet infrastructure. 406 Those applications that require stronger security are encouraged to use 407 authentication headers, or encrypted payloads, and/or ATM-layer security 408 services [16], when such services become available. 410 A current internet draft [17] defines security extensions for L2TP over 411 Non-IP networks. Future work on this draft should be closely 412 coordinated with work on [17]. 414 Note: When using LLC-encapsulated L2TP over a virtual connection, an 415 end point cannot assume that the PPP session authentication and related 416 security mechanisms also secure the other LLC encapsulated flows on that 417 same virtual connection. 419 11. Acknowledgments 421 This Internet Draft draws heavily on material in Internet Draft "PPP 422 Over ATM," , April 30, 1998, by George 423 Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and John Stephens; the 424 current internet draft on L2TP Over Frame Relay, by Vipin Rawat, Rene Tio, 425 and Rohit Verma; and an earlier internet draft on L2TP Over AAL5 and FUNI by 426 by Nagraj Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin. 428 Rene Tio contributed to the development of this draft. 430 12. References 432 [1] Valencia, A., et al., Layer Two Tunneling Protocol "L2TP", 433 Internet Draft May 1998. 434 Work in Progress. 436 [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 437 51, RFC 1661, July 1994. 439 [3] The ATM Forum, "ATM User-Network Interface Specification V3.1", 440 af-uni-0010.002, 1994. 442 [4] International Telecommunication Union, "B-ISDN ATM Adaptation Layer 443 (AAL) Specification", ITU-T Recommendation I.363, March, 1993. 445 [5] The ATM Forum, "Frame based User-to-Network Interface (FUNI) 446 Specification v2", af-saa-0088.000, May 1997. 448 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 449 Levels", BCP 14, RFC 2119, Harvard University, March 1997. 451 [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption 452 Layer 5", RFC 1483, July 1993. 454 [8] International Telecommunication Union, "Broadband Integrated 455 Service Digital Network (B-ISDN) Digital Subscriber Signaling 456 System No.2 (DSS2) User Network Interface Layer 3 Specification for 457 Basic Call/Connection Control", ITU-T Recommendation Q.2931, 458 Feb. 1995. 460 [9] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working 461 Implementation Agreement", FRF.8, April 1995. 463 [10] ISO/IEC DTR 9577.2, "Information technology - Telecommunications 464 and Information exchange between systems - Protocol Identification 465 in the network layer", 1995-08-16. 467 [11] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 468 "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. 470 [12] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC 1334, 471 Oct. 1992. 473 [13] W. Simpson, "The PPP Challenge Handshake Authentication Protocol 474 (CHAP)", RFC 1994, August 1996. 476 [14] G. Meyer, "The PPP Encryption Control Protocol (ECP)", RFC 1968, 477 June 1996. 479 [15] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol (DESE)", 480 RFC 1969, June 1996. 482 [16] ATM Forum Technical Committee, "ATM Security Framework V1.0", 483 Feb. 1998. 485 [17] P. Calhoun, M. Townsley, S. Vakil, and D. Grosser, "Layer Two 486 Tunneling Protocol Security Extensions for Non-IP Networks", 487 Internet Draft , July, 1998. 488 Work in Progress. 490 Chair's Address 492 The PPP Extensions working group can be contacted via the current chair: 494 Karl Fox 495 Ascend Communications 496 3518 Riverside Drive, Suite 101 497 Columbus, Ohio 43221 499 EMail: karl@ascend.com 501 Editor's Address 503 Questions about this memo can also be directed to: 505 Rollins Turner 506 Paradyne Corporation 507 8545 126th Avenue North 508 Largo, FL 33773 509 Tel: +1.727.530.2629 510 Email: rturner@eng.paradyne.com 512 Appendix A. Acronyms 514 AAL5 ATM Adaptation Layer Type 5 516 ATM Asynchronous Transfer Mode 518 B-LLI Broadband Low Layer Information 520 CPCS Common Part Convergence Sublayer 522 FUNI Frame based User-to-Network Interface 524 IANA Internet Assigned Numbers Authority 526 IE Information Element 528 L2TP Layer Two Tunneling Protocol 530 LAC L2TP Access Concentrator 532 LLC Logical Link Control 534 LNS L2TP Network Server 536 MTU Maximum Transfer Unit 538 MRU Maximum Receive Unit 540 NSP Network Service Provider 542 OUI Organizationally Unique Identifier 544 PDU Protocol Data Unit 546 PID Protocol Identifier 548 PPP Point to Point Protocol 550 PVC Permanent Virtual Circuit 552 SAP Service Access Point 554 SNAP Subnetwork Address Protcol 556 SVC Switched Virtual Circuit 558 VC Virtual Circuit