idnits 2.17.1 draft-ietf-pppext-l2tp-atm-02.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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 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 4 instances of too long lines in the document, the longest one being 6 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 452, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 455, 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: 10 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 Arthur Lin, Shasta Networks 3 April, 1999 Ajoy Singh, Motorola 4 Expires October 18, 1999 John Stephens, Cayman Systems 5 Rollins Turner, Paradyne 6 J. Senthilnathan , 3Com 8 L2TP Over AAL5 and FUNI 10 12 Status Of This Memo 14 This document is an internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress''. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The Layer Two Tunneling Protocol (L2TP) [1] provides a standard 36 method for transporting the link layer of PPP [2] between a dial-up 37 server and a Network Access Server, using a network connection in 38 lieu of a physical point to point connection. This document 39 describes the use of an ATM network for the underlying network 40 connection. Both ATM UNI [3] with ATM Adaptation Layer 5 [4] 41 (AAL5) and ATM with Frame based User-to-Network Interface (FUNI) 42 [5] are supported as interfaces to the ATM network. 44 Applicability 46 This specification is intended for implementations of L2TP that use ATM 47 to provide the communications link between the L2TP Access Concentrator 48 and the L2TP Network Server. 50 1. Introduction 52 The Point-to-Point Protocol, PPP, [2] is frequently used on the link 53 between a personal computer with a dial modem and a network service 54 provider, or NSP. The Layer Two Tunneling Protocol (L2TP) [1] enables a 55 dial-up server to provide access to a remote NSP by extending the PPP 56 connection through a tunnel in a network to which both it and the NSP 57 are directly connected. A "tunnel" is a network layer connection 58 between two nodes, used in the role of a data link layer connection 59 between those nodes, possibly as part of a different network. 61 In [1] the dial-up server is called an L2TP Access Concentrator, or LAC. 62 The remote device that provides access to a network is called an L2TP 63 Network Server, or LNS. L2TP uses a packet delivery service to create a 64 tunnel between the LAC and the LNS. "L2TP is designed to be largely 65 insulated from the details of the media over which the tunnel is 66 established; L2TP requires only that the tunnel media provide packet 67 oriented point-to-point connectivity" [1]. An ATM network, with either 68 AAL5 or FUNI, offers a suitable form of packet oriented connection. 70 This standard supplements [1] by providing details specific to the use 71 of AAL5 and FUNI for the point-to-point connection between LAC and LNS. 73 2. Conventions 75 2.1 Requirements Keywords 77 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD 78 NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, 79 are to be interpreted as described in [6]. 81 2.2 Terminology 83 A list of acronyms used in this document is given at the end of the 84 document as Appendix A. 86 3. AAL5 Layer Service Interface 88 L2TP treats the underlying ATM AAL5 layer service as a bit-synchronous 89 point-to-point link. In this context, the L2TP link corresponds to an 90 ATM AAL5 virtual circuit (VC.) The VC MUST be full-duplex, point to 91 point, and it MAY be either dedicated (i.e., permanent, set up by 92 provisioning) or switched (set up on demand.) 94 The AAL5 message mode service, in the non-assured mode of operation, 95 without the corrupted delivery option MUST be used. 97 Interface Format - The L2TP/AAL5 layer boundary presents an octet 98 service interface to the AAL5 layer. There is no provision for sub- 99 octets to be supplied or accepted. 101 3.1 Maximum Transfer Unit 103 Each L2TP PDU MUST be transported within a single AAL5 PDU. Therefore 104 the maximum transfer unit (MTU) of the AAL5 connection constrains the 105 MTU of the L2TP tunnel that uses the connection and the MTU of all PPP 106 connections that use the tunnel. (PPP refers to this as Maximum Receive 107 Unit, or MRU [2]. In the UNI 3.1 specification it is Forward and 108 Backward Maximum CPCS-SDU Size [3].) 110 An implementation MUST support a PPP MRU of at least 1500 bytes. 112 An implementation SHOULD use a larger MTU than the minimum value 113 specified above. It is RECOMMENDED that an implementation support an IP 114 packet of at least 9180 bytes in the PPP PDU. 116 3.2 Quality of Service 118 In order to provide a desired quality of service, and possibly different 119 qualities of service to different client connections, an implementation 120 MAY use more than one AAL5 connection between LAC and LNS. 122 A tunnel is initially created over an AAL5 connection. A subsequent 123 call to the LAC may require that the LAC open a new AAL5 connection to 124 satisfy QoS requirements of that call. If an implementation determines 125 that multiple tunnels are required to a given peer, each tunnel SHALL be 126 based on a separate AAL5 connection. 128 3.3 ATM Connection Parameters 130 The L2TP layer does not impose any restrictions regarding transmission 131 rate or the underlying ATM layer traffic descriptor parameters. 133 Specific traffic parameters MAY be set for a PVC connection by agreement 134 between the communicating parties. The caller MAY request specific 135 traffic parameters at the time an SVC connection is set up. 137 4. Multi-Protocol Encapsulation 139 This specification uses the principles, terminology, and frame structure 140 described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" 141 [7] (RFC 1483). The purpose of this specification is not to reiterate 142 what is already standardized in [7], but to specify how the mechanisms 143 described in [7] are to be used to map L2TP onto an AAL5-based ATM 144 network. (There is a current internet draft [17] updating [7].) 146 As specified in [7], L2TP PDUs shall be carried in the Payload field of 147 Common Part Convergence Sublayer (CPCS) PDUs of ATM Adaptation Layer 148 type 5 (AAL5), and the Service Specific Convergence Sublayer (SSCS) of 149 AAL5 shall be empty. 151 Section 1 of [7] defines two mechanisms for identifying the protocol 152 encapsulated in the AAL5 PDU's payload field: 154 1. Virtual circuit (VC) based multiplexing. 155 2. Logical Link Control (LLC) encapsulation. 157 In the first mechanism, the payload's protocol type is implicitly agreed 158 to by the end points for each virtual circuit using provisioning or 159 control plane procedures. This mechanism will be referred to as "VC- 160 multiplexed L2TP". 162 In the second mechanism, the payload's protocol type is explicitly 163 identified in each AAL5 PDU by an IEEE 802.2 LLC header. This mechanism 164 will be referred to as "LLC encapsulated L2TP". 166 An L2TP implementation: 168 1. MUST support LLC encapsulated L2TP on PVCs. 170 2. MAY support LLC encapsulated L2TP on SVCs. 172 3. MAY support VC-multiplexed L2TP on PVCs or SVCs. 174 When a PVC is used, the endpoints must be configured to use one of the 175 two encapsulation methods. 177 If an implementation supports switched VC connections, it MUST use the 178 Q.2931 [8] Annex C procedure to negotiate connection setup, encoding the 179 Broadband Lower Layer Interface (B-LLI) information element to signal 180 either VC-multiplexed L2TP or LLC encapsulated L2TP. The details of 181 this control plane procedure are described in section 7. 183 If an implementation is connecting through a Frame Relay/ATM FRF.8 [9] 184 service inter-working unit, then it MUST use LLC encapsulated L2TP. 186 5. LLC Encapsulated L2TP Over AAL5 188 When LLC encapsulation is used, the Payload field of the AAL5 CPCS PDU 189 SHALL be encoded as shown in figure 1. The pertinent fields in that 190 diagram are: 192 1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA 193 followed by a frame type of Un-numbered Information (value 0x03). 194 This LLC header indicates that an IEEE 802.1a SNAP header follows 195 [7]. 197 2. IEEE 802.1a SNAP Header: The three octet Organizationally 198 Unique Identifier (OUI) value of 0x00-00-5E identifies IANA 199 (Internet Assigned Numbers Authority.) The two octet Protocol 200 Identifier (PID) identifies L2TP as the encapsulated protocol. The 201 PID value is to be determined by IANA. 203 3. The L2TP PDU. 205 +-------------------------+ -------- 206 | Destination SAP (0xAA) | ^ 207 +-------------------------+ | 208 | Source SAP (0xAA) | LLC header 209 +-------------------------+ | 210 | Frame Type = UI (0x03) | V 211 +-------------------------+ -------- 212 | OUI (0x00-00-5E)| | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header 214 | PID (2 octets) | | 215 +-------------------------+ -------- 216 | | ^ 217 | | | 218 | | L2TP PDU 219 | | | 220 | | | 221 | | V 222 +-------------------------+ -------- 224 Figure 1. 226 Note: The format of the overall AAL5 CPCS PDU is shown in the next 227 section. 229 The end points MAY be bi-laterally provisioned to send other LLC- 230 encapsulated protocols besides L2TP across the same virtual connection. 231 However, they MUST NOT send packets belonging to any protocol that has 232 an active NCP within a PPP session carried by the L2TP tunnel. 234 6. Virtual Circuit Multiplexed L2TP Over AAL5 236 VC-multiplexed L2TP over AAL5 is an alternative technique to LLC 237 encapsulated L2TP over AAL5 when both LAC and LNS use AAL5 as opposed to 238 FUNI. In this case the L2TP PDU is the AAL5 Payload. This is sometimes 239 called "Null encapsulation." 241 The AAL5 CPCS PDU format is shown in figure 2. 243 AAL5 CPCS-PDU Format 245 +-------------------------------+ ------- 246 | . | ^ 247 | . | | 248 | CPCS-PDU Payload | L2TP PDU 249 | up to 2^16 - 1 octets) | | 250 | . | V 251 +-------------------------------+ ------- 252 | PAD ( 0 - 47 octets) | 253 +-------------------------------+ ------- 254 | CPCS-UU (1 octet ) | ^ 255 +-------------------------------+ | 256 | CPI (1 octet ) | | 257 +-------------------------------+CPCS-PDU Trailer 258 | Length (2 octets) | | 259 +-------------------------------| | 260 | CRC (4 octets) | V 261 +-------------------------------+ ------- 263 Figure 2. 265 The Common Part Convergence Sub-layer (CPCS) PDU Payload field contains 266 user information up to 2^16 - 1 octets. 268 The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such 269 that the last 48 octet cell payload created by the SAR sublayer will 270 have the CPCS-PDU Trailer right justified in the cell. 272 The CPCS-UU (User-to-User indication) field is used to transparently 273 transfer CPCS user to user information. The field has no function under 274 the multi-protocol ATM encapsulation and MAY be set to any value. 276 The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 277 bits. Possible additional functions are for further study in ITU-T. 278 When only the 64 bit alignment function is used, this field SHALL be 279 coded as 0x00. 281 The Length field indicates the length, in octets, of the Payload field. 282 The maximum value for the Length field is 65535 octets. A Length field 283 coded as 0x00 MAY be used for the abort function. 285 The CRC field SHALL be computed over the entire CPCS-PDU except the CRC 286 field itself. 288 The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in [1]. 290 7. Out-Of-Band Control Plane Signaling 292 7.1 Connection Setup 294 A switched VC connection can originate at either the LAC or the LNS. An 295 implementation that supports the use of SVCs MUST be able to both 296 originate and respond to SVC setup requests. 298 When originating a switched virtual circuit AAL5 connection, the caller 299 MUST request in the SETUP message either VC-multiplexed L2TP, LLC 300 encapsulated L2TP, or else both VC-multiplexed and LLC-encapsulated 301 L2TP. The Broadband Low Layer Information (B-LLI) information element 302 SHALL be used to specify the requested encapsulation method. When a 303 caller is offering both techniques, the two B-LLI information elements 304 SHALL be encoded within a Broadband Repeat Indicator information element 305 in the order of the sender's preference. 307 An implementation MUST be able to accept an incoming call that offers 308 LLC encapsulated L2TP in the caller's request. The called 309 implementation MUST reject a call set up request that only offers an 310 encapsulation that it does not support. Implementations originating a 311 call offering both protocol encapsulation techniques MUST be able to 312 accept the use of either encapsulation technique. 314 When originating an LLC encapsulated call that is to carry an L2TP 315 payload, the ITU Q.2931 [8] B-LLI element user information layer 2 316 protocol field SHALL be encoded to select LAN Logical Link Control 317 (ISO/IEC8802-2) in octet 6. See RFC 1755 [11] appendix A for an 318 example. 320 When originating a VC-multiplexed call that is to carry an L2TP payload, 321 the ITU Q.2931 [8] B-LLI element user information layer 3 protocol field 322 SHALL be encoded to select ISO/IEC TR 9577 [10] in octet 7. The 323 extension octets specify an IPI value of L2TP (TBD). The AAL5 frame's 324 payload field will always contain an L2TP PDU. 326 If the caller offers both encapsulation methods and the called peer 327 accepts the call, the called peer SHALL specify the encapsulation method 328 by including exactly one B-LLI IE in the Connect message. 330 If an SVC tunnel is reset in accordance with section 4.1 of [1], both 331 ends MUST clear the connection. Any user sessions on the tunnel will be 332 terminated by the reset. Either end MAY attempt to re-establish the 333 tunnel upon receipt of a new request from a client. 335 7.2 Connection Setup Failure 337 When a connection setup fails, the L2TP entity that attempted the 338 connection setup MAY consider the called entity unreachable until 339 notified that the unreachable entity is available. The conditions under 340 which an entity determines that another is unreachable and how it 341 determines that the other is available again are implementation 342 decisions. 344 7.3 Connection Teardown 346 When there are no active sessions on an SVC tunnel, either end MAY 347 optionally clear the connection. 349 [Note: There is a race condition when one end starts to clear the 350 connection at the same time the other end starts to establish a new 351 session. Further work is needed here.] 353 8. Detection And Recovery From Unsolicited L2TP Encapsulation 354 Transitions 356 [This section requires futher work.] 358 9. Connection Failure 360 Upon notification that an AAL5 SVC connection has been cleared, an 361 implementation SHALL tear down the tunnel and return the control 362 connection to the Idle state. 364 If an AAL5 PVC enters the "Stopped" state, an implementation SHALL tear 365 down the tunnel and return the control connection to the Idle state. 367 10. Security Considerations 369 ATM networks, being virtual circuit based, are generally less vulnerable 370 to security attacks than IP based networks. The probability of a 371 security breach caused by misrouted ATM cells is considered to be 372 negligible. 374 The L2TP base protocol provides a mechanism for tunnel authentication 375 during the Establishment phase. This authentication has the same 376 security attributes as CHAP [12, 13], and provides reasonable protection 377 against replay attacks. 379 Since L2TP encapsulates a PPP payload, the same PAP/CHAP authentication 380 protocols that are widely used for Internet dial up access can be used 381 at both LAC and LNS to authenticate tunnel users. PPP encryption [14, 382 15] can also be used to encrypt the PPP payload through L2TP. As a 383 consequence, L2TP Over AAL5 security is at parity with those practices already 384 established by the existing Internet infrastructure. 386 Those applications that require stronger security are encouraged to use 387 authentication headers, or encrypted payloads, and/or ATM-layer security 388 services [16], when such services become available. 390 Note: When using LLC-encapsulated L2TP over a virtual connection, an 391 end point cannot assume that the PPP session authentication and related 392 security mechanisms also secure the other LLC encapsulated flows on that 393 same virtual connection. 395 11. Acknowledgments 397 This Internet Draft draws heavily on material in Internet Draft "PPP 398 Over ATM," , April 30, 1998, by George 399 Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and John Stephens; the 400 current internet draft on L2TP Over Frame Relay, by Vipin Rawat, Rene Tio, 401 and Rohit Verma; and an earlier internet draft on L2TP Over AAL5 and FUNI by 402 by Nagraj Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin. 404 Rene Tio contributed to the development of this draft. 406 12. References 408 [1] Rubens, A., et al., Layer Two Tunneling Protocol "L2TP", 409 Internet Draft Feb. 1999. 410 Work in Progress. 412 [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 413 51, RFC 1661, July 1994. 415 [3] The ATM Forum, "ATM User-Network Interface Specification V3.1", 416 af-uni-0010.002, 1994. 418 [4] International Telecommunication Union, "B-ISDN ATM Adaptation Layer 419 (AAL) Specification", ITU-T Recommendation I.363, March, 1993. 421 [5] The ATM Forum, "Frame based User-to-Network Interface (FUNI) 422 Specification v2", af-saa-0088.000, May 1997. 424 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 425 Levels", BCP 14, RFC 2119, Harvard University, March 1997. 427 [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption 428 Layer 5", RFC 1483, July 1993. 430 [8] International Telecommunication Union, "Broadband Integrated 431 Service Digital Network (B-ISDN) Digital Subscriber Signaling 432 System No.2 (DSS2) User Network Interface Layer 3 Specification for 433 Basic Call/Connection Control", ITU-T Recommendation Q.2931, 434 Feb. 1995. 436 [9] The Frame Relay Forum, "Frame Relay/ATM PVC Service Inter-working 437 Implementation Agreement", FRF.8, April 1995. 439 [10] ISO/IEC DTR 9577.2, "Information technology - Telecommunications 440 and Information exchange between systems - Protocol Identification 441 in the network layer", 1995-08-16. 443 [11] M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis, 444 "ATM Signaling Support for IP over ATM", RFC 1755, February 1995. 446 [12] B. Lloyd, W. Simpson, "PPP Authentication Protocols", RFC 1334, 447 Oct. 1992. 449 [13] W. Simpson, "The PPP Challenge Handshake Authentication Protocol 450 (CHAP)", RFC 1994, August 1996. 452 [14] G. Meyer, "The PPP Encryption Control Protocol (ECP)", RFC 1968, 453 June 1996. 455 [15] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol (DESE)", 456 RFC 1969, June 1996. 458 [16] ATM Forum Technical Committee, "ATM Security Framework V1.0", 459 Feb. 1998. 461 [17] J. Heinanen, D. Grossman, "Multiprotocol Encapsulation over 462 ATM Adaptation Layer 5", Internet Draft Oct. 1998. Work in Progress. 465 Chair's Address 467 The PPP Extensions working group can be contacted via the current chair: 469 Karl Fox 470 Ascend Communications 471 3518 Riverside Drive, Suite 101 472 Columbus, Ohio 43221 474 EMail: karl@ascend.com 476 Editor's Address 478 Questions about this memo can also be directed to: 480 Rollins Turner 481 Paradyne Corporation 482 8545 126th Avenue North 483 Largo, FL 33773 484 Tel: +1.727.530.2629 485 Email: rturner@eng.paradyne.com 487 Ajoy Singh 488 Motorola 489 1421 West Shure Dr, 490 Arlington Heights, IL 60004 491 Tel: +1.847.632.6941 492 Fax: +1.847.632.5181 493 Email: asingh1@email.mot.com 495 Appendix A. Acronyms 497 AAL5 ATM Adaptation Layer Type 5 499 ATM Asynchronous Transfer Mode 501 B-LLI Broadband Low Layer Information 503 CPCS Common Part Convergence Sublayer 505 FUNI Frame based User-to-Network Interface 507 IANA Internet Assigned Numbers Authority 509 IE Information Element 511 L2TP Layer Two Tunneling Protocol 513 LAC L2TP Access Concentrator 515 LLC Logical Link Control 517 LNS L2TP Network Server 519 MTU Maximum Transfer Unit 521 MRU Maximum Receive Unit 523 NSP Network Service Provider 525 OUI Organizationally Unique Identifier 527 PDU Protocol Data Unit 529 PID Protocol Identifier 531 PPP Point to Point Protocol 533 PVC Permanent Virtual Circuit 535 SAP Service Access Point 537 SNAP Subnetwork Address Protcol 539 SVC Switched Virtual Circuit 541 VC Virtual Circuit