1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Network Working Group A. Singh
Request for Comments: 3355 Motorola
Category: Standards Track R. Turner
Paradyne
R. Tio
S. Nanji
Redback Networks
August 2002
<span class="h1">Layer Two Tunnelling Protocol (L2TP)</span>
<span class="h1">Over ATM Adaptation Layer 5 (AAL5)</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The Layer Two Tunneling Protocol (L2TP) provides a standard method
for transporting the link layer of the Point-to-Point Protocol (PPP)
between a dial-up server and a Network Access Server, using a network
connection in lieu of a physical point-to-point connection. This
document describes the use of an Asynchronous Transfer Mode (ATM)
network for the underlying network connection. ATM User-Network
Interface (UNI) Signaling Specification Version 4.0 or Version 3.1
with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the
ATM network.
Applicability
This specification is intended for implementations of L2TP that use
ATM to provide the communications link between the L2TP Access
Concentrator and the L2TP Network Server.
<span class="grey">Singh, et. al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Point-to-Point Protocol (PPP) [<a href="./rfc1661" title=""The Point-to-Point Protocol (PPP)"">RFC1661</a>], is frequently used on
the link between a personal computer with a dial modem and a network
service provider, or NSP. The Layer Two Tunneling Protocol (L2TP)
[<a href="./rfc2661" title=""Layer Two Tunneling Protocol (L2TP)"">RFC2661</a>] enables a dial-up server to provide access to a remote NSP
by extending the PPP connection through a tunnel in a network to
which both it and the NSP are directly connected. A "tunnel" is a
network layer connection between two nodes, used in the role of a
data link layer connection between those nodes, possibly as part of a
different network. In [<a href="./rfc2661" title=""Layer Two Tunneling Protocol (L2TP)"">RFC2661</a>] the dial-up server is called an L2TP
Access Concentrator, or LAC. The remote device that provides access
to a network is called an L2TP Network Server, or LNS. L2TP uses a
packet delivery service to create a tunnel between the LAC and the
LNS. "L2TP is designed to be largely insulated from the details of
the media over which the tunnel is established; L2TP requires only
that the tunnel media provide packet oriented point-to-point
connectivity" [<a href="./rfc2661" title=""Layer Two Tunneling Protocol (L2TP)"">RFC2661</a>]. An ATM network with AAL5 offers a suitable
form of packet oriented connection. This standard supplements
[<a href="./rfc2661" title=""Layer Two Tunneling Protocol (L2TP)"">RFC2661</a>] by providing details specific to the use of AAL5 for a
point-to-point connection between LAC and LNS.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions</span>
Requirements keywords The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
A list of acronyms used in this document is given at the end of the
document as <a href="#appendix-A">Appendix A</a>.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. AAL5 Layer Service Interface</span>
L2TP treats the underlying ATM AAL5 layer service as a bit-
synchronous point-to-point link. In this context, the L2TP link
corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be
full-duplex, point to point, and it MAY be either dedicated (i.e.,
permanent, set up by provisioning) or switched (set up on demand.)
The AAL5 message mode service, in the non-assured mode of operation,
without the corrupted delivery option MUST be used.
Interface Format - The L2TP/AAL5 layer boundary presents an octet
service interface to the AAL5 layer. There is no provision for sub-
octets to be supplied or accepted.
<span class="grey">Singh, et. al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Maximum Transfer Unit</span>
Each L2TP PDU MUST be transported within a single AAL5 PDU.
Therefore the maximum transfer unit (MTU) of the AAL5 connection
constrains the MTU of the L2TP tunnel that uses the connection and
the MTU of all PPP connections that use the tunnel. ([<a href="./rfc1661" title=""The Point-to-Point Protocol (PPP)"">RFC1661</a>]
refers to this as Maximum Receive Unit, or MRU. In [<a href="#ref-SIG31" title=""ATM User-Network Interface Specification V3.1"">SIG31</a>], it is
the Forward and Backward Maximum CPCS-SDU Size.)
An implementation MUST support a PPP MRU of at least 1500 bytes.
An implementation SHOULD use a larger MTU than the minimum value
specified above. It is RECOMMENDED that an implementation support an
IP packet of at least 9180 bytes in the PPP PDU.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Quality of Service</span>
In order to provide a desired Quality of Service (QoS), and possibly
different qualities of service to different client connections, an
implementation MAY use more than one AAL5 connection between LAC and
LNS.
QoS mechanisms, such as Differentiated UBR [<a href="#ref-DUBR" title=""Addendum to TM 4.1: Differentiated UBR"">DUBR</a>], that could involve
inverse multiplexing a tunnel across multiple VCs are for further
study. QoS mechanisms applicable to a single tunnel corresponding to
a single VC, are independent of the ATM transport and out of scope of
this document.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a> ATM Connection Parameters</span>
The L2TP layer does not impose any restrictions regarding
transmission rate or the underlying ATM layer traffic descriptor
parameters.
Specific traffic parameters MAY be set for a PVC connection by
agreement between the communicating parties. The caller MAY request
specific traffic parameters at the time an SVC connection is set up.
Autoconfiguration of end-systems for PVCs can be facilitated by the
use of the optional ILMI 4.0 extensions documented in [<a href="#ref-ILMIA" title=""Addendum to the ILMI Auto-configuration extension"">ILMIA</a>]. This
provides comparable information to the IEs used for control plane
connection establishment.
<span class="grey">Singh, et. al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Multi-Protocol Encapsulation</span>
This specification uses the principles, terminology, and frame
structure described in "Multiprotocol Encapsulation over ATM
Adaptation Layer 5" [<a href="./rfc2684" title=""Multiprotocol Encapsulation over ATM Adaptation Layer 5"">RFC2684</a>]. The purpose of this specification is
not to reiterate what is already standardized in [<a href="./rfc2684" title=""Multiprotocol Encapsulation over ATM Adaptation Layer 5"">RFC2684</a>], but to
specify how the mechanisms described in [<a href="./rfc2684" title=""Multiprotocol Encapsulation over ATM Adaptation Layer 5"">RFC2684</a>] are to be used to
map L2TP onto an AAL5-based ATM network.
As specified in [<a href="./rfc2684" title=""Multiprotocol Encapsulation over ATM Adaptation Layer 5"">RFC2684</a>], L2TP PDUs shall be carried in the payload
field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and
the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be
empty.
<a href="./rfc2684#section-1">Section 1 of [RFC2684]</a> defines two mechanisms for identifying the
protocol encapsulated in the AAL5 PDU's payload field:
1. Virtual circuit (VC) based multiplexing.
2. Logical Link Control (LLC) encapsulation.
In the first mechanism, the payload's protocol type is implicitly
agreed to by the end points for each virtual circuit using
provisioning or control plane procedures. This mechanism will be
referred to as "VC-multiplexed L2TP".
In the second mechanism, the payload's protocol type is explicitly
identified in each AAL5 PDU by an IEEE 802.2 LLC header. This
mechanism will be referred to as "LLC encapsulated L2TP".
An L2TP implementation:
1. MUST support LLC encapsulated L2TP on PVCs.
2. MAY support LLC encapsulated L2TP on SVCs.
3. MAY support VC-multiplexed L2TP on PVCs or SVCs.
When a PVC is used, the endpoints must be configured to use one of
the two encapsulation methods.
If an implementation supports SVCs, it MUST use the [<a href="#ref-Q.2931" title=""Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control"">Q.2931</a>] Annex C
procedure to negotiate connection setup, encoding the Broadband Lower
Layer Interface (B-LLI) information element (IE) to signal either
VC-multiplexed L2TP or LLC encapsulated L2TP. The details of this
control plane procedure are described in <a href="#section-7">section 7</a>.
If an implementation is connecting through a Frame Relay/ATM FRF.8
[<a href="#ref-FRF8" title=""Frame Relay/ATM PVC Service Interworking Implementation Agreement"">FRF8</a>] service inter-working unit, then it MUST use LLC encapsulated
L2TP.
<span class="grey">Singh, et. al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. LLC Encapsulated L2TP over AAL5</span>
When LLC encapsulation is used, the payload field of the AAL5 CPCS
PDU SHALL be encoded as shown in Figure 1. The pertinent fields in
that diagram are:
1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA
followed by a frame type of Un-numbered Information (value
0x03). This LLC header indicates that an IEEE 802.1a SNAP
header follows [<a href="./rfc2684" title=""Multiprotocol Encapsulation over ATM Adaptation Layer 5"">RFC2684</a>].
2. IEEE 802.1a SNAP Header: The three octet Organizationally
Unique Identifier (OUI) value of 0x00-00-5E identifies IANA
(Internet Assigned Numbers Authority.) The two octets Protocol
Identifier (PID) identifies L2TP as the encapsulated protocol.
The PID value is 0x0007.
3. The L2TP PDU:
Figure 1 - LLC Encapsulated L2TP PDU
+-------------------------+ --------
| Destination SAP (0xAA) | ^
+-------------------------+ |
| Source SAP (0xAA) | LLC header
+-------------------------+ |
| Frame Type = UI (0x03) | V
+-------------------------+ --------
| OUI (0x00-00-5E)| |
+-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header
| PID (0x00-07) | |
+-------------------------+ --------
| | |
| | L2TP PDU
| | |
+-------------------------+ --------
Note: The format of the overall AAL5 CPCS PDU is shown in the next
section.
The end points MAY be bi-laterally provisioned to send other LLC-
encapsulated protocols besides L2TP across the same virtual
connection.
<span class="grey">Singh, et. al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Virtual Circuit Multiplexed L2TP over AAL5</span>
VC-multiplexed L2TP over AAL5 is an alternative technique to LLC
encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5
payload without an LLC header. This is sometimes called "Null
encapsulation."
Figure 2 - AAL5 CPCS-PDU Format
+-------------------------------+ -------
| . | ^
| . | |
| CPCS-PDU payload | L2TP PDU
| up to 2^16 - 1 octets) | |
| . | V
+-------------------------------+ -------
| PAD ( 0 - 47 octets) |
+-------------------------------+ -------
| CPCS-UU (1 octet ) | ^
+-------------------------------+ |
| CPI (1 octet ) | |
+-------------------------------+CPCS-PDU Trailer
| Length (2 octets) | |
+-------------------------------| |
| CRC (4 octets) | V
+-------------------------------+ -------
The Common Part Convergence Sub-layer (CPCS) PDU payload field
contains user information up to 2^16 - 1 octets.
The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
such that the last 48 octet cell payload created by the SAR sublayer
will have the CPCS-PDU Trailer right justified in the cell.
The CPCS-UU (User-to-User indication) field is used to transparently
transfer CPCS user to user information. The field has no function
under the multi-protocol ATM encapsulation and MAY be set to any
value.
The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
64 bits. Possible additional functions are for further study in
ITU-T. When only the 64 bit alignment function is used, this field
SHALL be coded as 0x00.
The Length field indicates the length, in octets, of the payload
field. The maximum value for the Length field is 65535 octets. A
Length field coded as 0x00 MAY be used for the abort function.
<span class="grey">Singh, et. al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
The CRC field is computed over the entire CPCS-PDU except the CRC
field itself.
The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in
[<a href="./rfc2661" title=""Layer Two Tunneling Protocol (L2TP)"">RFC2661</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Out-of-Band Control Plane Signaling</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a> Connection Setup</span>
An SVC connection can originate at either the LAC or the LNS. An
implementation that supports the use of SVCs MUST be able to both
originate and respond to SVC setup requests. Except for the B-LLI IE
specified below, all other IEs required for ATM User-Network
Interface (UNI) Signaling Specification Version 4.0 [<a href="#ref-SIG40" title=""ATM User-Network Interface (UNI) Signaling Specification Version 4.0"">SIG40</a>] should be
encoded as per [<a href="./rfc2331" title=""ATM Signaling Support for IP over ATM - UNI Signaling 4.0 Update"">RFC2331</a>].
When originating an SVC AAL5 connection, the caller MUST request in
the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP,
or both VC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL
be used to specify the requested encapsulation method. When a caller
is offering both encapsulations, the two B-LLI IEs SHALL be encoded
within a Broadband Repeat Indicator information element in the order
of the sender's preference.
An implementation MUST be able to accept an incoming call that offers
LLC encapsulated L2TP in the caller's request. The called peer's
implementation MUST reject a call setup request that only offers an
encapsulation that it does not support. Implementations originating
a call offering both protocol encapsulation techniques MUST be able
to accept the use of either encapsulation techniques.
When originating an LLC encapsulated call that is to carry an L2TP
payload, the [<a href="#ref-Q.2931" title=""Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control"">Q.2931</a>] B-LLI IE user information layer 2 protocol
field SHALL be encoded to select LAN Logical Link Control
(ISO/IEC8802-2) in octet 6. See <a href="./rfc2331#appendix-A">[RFC2331] Appendix A</a> for an example.
When originating a VC-multiplexed call that is to carry an L2TP
payload, the [<a href="#ref-Q.2931" title=""Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control"">Q.2931</a>] B-LLI IE user information layer 2 protocol
field SHALL be encoded to select no layer 2 protocol in octet 6 and
layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577
[<a href="#ref-ISO9577" title=""Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer"">ISO9577</a>] in octet 7. Furthermore, as per DSL Forum TR-037
[<a href="#ref-DSLF037" title=""Auto-Configuration for the Connection Between the DSL Broadband Network Termination (B-NT) and the Network using ATM"">DSLF037</a>], the extension octets specify VC-multiplexed L2TP by using
the SNAP IPI, followed by an OUI owned by IANA, followed by the PID
assigned by IANA for L2TP. Thus, the User Information layer 3
protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's
<span class="grey">Singh, et. al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
payload field will always contain an L2TP PDU. The SNAP IPI is
employed only to use the IANA L2TP protocol value to specify the VC-
multiplexed PDU.
If the caller offers both encapsulation methods and the called peer
accepts the call, the called peer SHALL specify the encapsulation
method by including exactly one B-LLI IE in the Connect message.
If an SVC tunnel is reset in accordance with <a href="./rfc2661#section-4.1">section 4.1 of
[RFC2661]</a>, both ends MUST clear the SVC. Any user sessions on the
tunnel will be terminated by the reset. Either end MAY attempt to
re-establish the tunnel upon receipt of a new request from a client.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a> Connection Setup Failure</span>
When a connection setup fails, the L2TP entity that attempted the
connection setup MAY consider the called entity unreachable until
notified that the unreachable entity is available. The conditions
under which an entity determines that another is unreachable and how
it determines that the other is available again are implementation
decisions.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a> Connection Teardown</span>
When there are no active sessions on an SVC tunnel, either end MAY
optionally clear the connection.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Connection Failure</span>
Upon notification that an AAL5 SVC connection has been cleared, an
Implementation SHALL tear down the tunnel and return the control
connection to the idle state.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The Layer Two Tunneling Protocol base specification [<a href="./rfc2661" title=""Layer Two Tunneling Protocol (L2TP)"">RFC2661</a>]
discusses basic security issues regarding L2TP tunneling. It is
possible that the L2TP over AAL5 tunnel security may be compromised
by the attack of ATM transport network itself. The ATM Forum has
published a security framework [<a href="#ref-AFSEC1" title=""ATM Security Framework Version 1.0"">AFSEC1</a>] and a security specification
[<a href="#ref-AFSEC2" title=""ATM Security Specification v1.1"">AFSEC2</a>] that define procedures to guard against common threats to an
ATM transport network. Applications that require protection against
threats to an ATM switching network are encouraged to use
authentication headers, or encrypted payloads, and/or the ATM-layer
security services described in [<a href="#ref-AFSEC2" title=""ATM Security Specification v1.1"">AFSEC2</a>].
<span class="grey">Singh, et. al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
This document draws heavily on material from: "PPP Over AAL5" (<a href="./rfc2364">RFC</a>
<a href="./rfc2364">2364</a>) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and
John Stephens and an earlier document of L2TP over AAL5 by Nagraj
Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin.
Special thanks to Mike Davison, Arthur Lin, John Stevens for making
significant contributions to the initial version of this document.
Special thanks to David Allan of Nortel for his invaluable review of
this document.
The security section of this document is based upon <a href="./rfc3337">RFC 3337</a>, "Class
Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2
(AAL2)", by Bruce Thompson, Bruce Buffam and Thima Koren.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
[<a id="ref-RFC2661">RFC2661</a>] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G.,
Zorn, G. and B. Palter, "Layer Two Tunneling Protocol
(L2TP)", <a href="./rfc2661">RFC 2661</a>, August 1999.
[<a id="ref-RFC1661">RFC1661</a>] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, <a href="./rfc1661">RFC 1661</a>, July 1994.
[<a id="ref-SIG31">SIG31</a>] The ATM Forum, "ATM User-Network Interface Specification
V3.1", af-uni-0010.002, 1994.
[<a id="ref-ITU93">ITU93</a>] International Telecommunication Union, "B-ISDN ATM
Adaptation Layer (AAL) Specification", ITU-T Recommendation
I.363, March 1993.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2684">RFC2684</a>] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", <a href="./rfc2684">RFC 2684</a>, September 1999.
[<a id="ref-Q.2931">Q.2931</a>] International Telecommunication Union, "Broadband
Integrated Service Digital Network (B-ISDN) Digital
Subscriber Signaling System No.2 (DSS2) User Network
Interface Layer 3 Specification for Basic Call/Connection
Control", ITU-T Recommendation Q.2931, Feb. 1995.
[<a id="ref-FRF8">FRF8</a>] The Frame Relay Forum, "Frame Relay/ATM PVC Service
Interworking Implementation Agreement", FRF.8, April 1995.
<span class="grey">Singh, et. al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
[<a id="ref-ISO9577">ISO9577</a>] ISO/IEC DTR 9577.2, "Information technology -
Telecommunications and Information exchange between systems
- Protocol Identification in the network layer", 1995-08-
16.
[<a id="ref-RFC2331">RFC2331</a>] Maher, M., "ATM Signaling Support for IP over ATM - UNI
Signaling 4.0 Update", <a href="./rfc2331">RFC 2331</a>, April 1998.
[<a id="ref-DSLF037">DSLF037</a>] DSL Forum Technical Report TR-037, "Auto-Configuration for
the Connection Between the DSL Broadband Network
Termination (B-NT) and the Network using ATM", March 2001.
[<a id="ref-SIG40">SIG40</a>] ATM Forum, "ATM User-Network Interface (UNI) Signaling
Specification Version 4.0", af-sig-0061.000, finalized July
1996; available at <a href="ftp://ftp.atmforum.com/pub">ftp://ftp.atmforum.com/pub</a>.
[<a id="ref-DUBR">DUBR</a>] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af-
tm-0149.000, finalized July, 2000; available at
<a href="ftp://ftp.atmforum.com/pub">ftp://ftp.atmforum.com/pub</a>
[<a id="ref-ILMIA">ILMIA</a>] ATM Forum, "Addendum to the ILMI Auto-configuration
extension", af-nm-00165.000, April 2001.
[<a id="ref-AFSEC1">AFSEC1</a>] The ATM Forum, "ATM Security Framework Version 1.0", af-
sec-0096.000, February 1998
[<a id="ref-AFSEC2">AFSEC2</a>] The ATM Forum, "ATM Security Specification v1.1", af-sec-
0100.002, March 2001
<span class="grey">Singh, et. al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acronyms</span>
AAL5 ATM Adaptation Layer Type 5
ATM Asynchronous Transfer Mode
B-LLI Broadband Low Layer Information
CPCS Common Part Convergence Sublayer
IANA Internet Assigned Numbers Authority
IE Information Element
L2TP Layer Two Tunneling Protocol
LAC L2TP Access Concentrator
LLC Logical Link Control
LNS L2TP Network Server
MTU Maximum Transfer Unit
MRU Maximum Receive Unit
NSP Network Service Provider
OUI Organizationally Unique Identifier
PDU Protocol Data Unit
PID Protocol Identifier
PPP Point-to-Point Protocol
PVC Permanent Virtual Circuit
SAP Service Access Point
SNAP Subnetwork Address Protocol
SVC Switched Virtual Circuit
VC Virtual Circuit
<span class="grey">Singh, et. al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
Authors' Addresses
Rollins Turner
Paradyne Corporation
8545 126th Avenue North
Largo, FL 33773
EMail: rturner@eng.paradyne.com
Rene Tio
Redback Networks, Inc.
300 Holger Way
San Jose, CA 95134
EMail: tor@redback.com
Ajoy Singh
Motorola
1421 West Shure Dr,
Arlington Heights, IL 60004
EMail: asingh1@motorola.com
Suhail Nanji
Redback Networks, Inc.
300 Holger Way
Sunnyvale, CA 95134
EMail: suhail@redback.com
<span class="grey">Singh, et. al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3355">RFC 3355</a> L2TP Over AAL5 August 2002</span>
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Singh, et. al. Standards Track [Page 13]
</pre>
|
