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
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Network Working Group R. Aggarwal, Ed.
Request for Comments: 4719 Juniper Networks
Category: Standards Track M. Townsley, Ed.
M. Dos Santos, Ed.
Cisco Systems
November 2006
<span class="h1">Transport of Ethernet Frames over</span>
<span class="h1">Layer 2 Tunneling Protocol Version 3 (L2TPv3)</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 IETF Trust (2006).
Abstract
This document describes the transport of Ethernet frames over the
Layer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the
transport of Ethernet port-to-port frames as well as the transport of
Ethernet VLAN frames. The mechanism described in this document can
be used in the creation of Pseudowires to transport Ethernet frames
over an IP network.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Specification of Requirements ..............................<a href="#page-2">2</a>
<a href="#section-1.2">1.2</a>. Abbreviations ..............................................<a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. L2TPv3 Control Message Types ...............................<a href="#page-3">3</a>
<a href="#section-1.4">1.4</a>. Requirements ...............................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. PW Establishment ................................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. LCCE-LCCE Control Connection Establishment .................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. PW Session Establishment ...................................<a href="#page-4">4</a>
<a href="#section-2.3">2.3</a>. PW Session Monitoring ......................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. Packet Processing ...............................................<a href="#page-7">7</a>
<a href="#section-3.1">3.1</a>. Encapsulation .............................................<a href="#page-7">7</a>
<a href="#section-3.2">3.2</a>. Sequencing ................................................<a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. MTU Handling ..............................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Applicability Statement .........................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Congestion Control .............................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-8">8</a>. Contributors ...................................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-11">11</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) can be used as a
control protocol and for data encapsulation to set up Pseudowires
(PWs) for transporting layer 2 Packet Data Units across an IP network
[<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]. This document describes the transport of Ethernet frames
over L2TPv3 including the PW establishment and data encapsulation.
The term "Ethernet" in this document is used with the intention to
include all such protocols that are reasonably similar in their
packet format to IEEE 802.3 [<a href="#ref-802.3" title=""IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for Information Technology - Telecommuincations and Information Exchange Between Systems - Local and Metropolitan Area Networks"">802.3</a>], including variants or extensions
that may or may not necessarily be sanctioned by the IEEE (including
such frames as jumbo frames, etc.). The term "VLAN" in this document
is used with the intention to include all virtual LAN tagging
protocols such as IEEE 802.1Q [<a href="#ref-802.1Q" title=""IEEE standard for local and metropolitan area networks virtual bridged local area networks"">802.1Q</a>], 802.1ad [<a href="#ref-802.1ad" title=""IEEE Std 802.1ad - 2005 IEEE Standard for Local and metropolitan area networks - virtual Bridged Local Area Networks, Amendment 4: Provider Bridges"">802.1ad</a>], etc.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Specification of Requirements</span>
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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>].
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Abbreviations</span>
AC Attachment Circuit (see [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>])
CE Customer Edge (Typically also the L2TPv3 Remote System)
LCCE L2TP Control Connection Endpoint (see [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>])
NSP Native Service Processing (see [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>])
PE Provider Edge (Typically also the LCCE) (see [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>])
PSN Packet Switched Network (see [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>])
PW Pseudowire (see [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>])
PWE3 Pseudowire Emulation Edge to Edge (Working Group)
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. L2TPv3 Control Message Types</span>
Relevant L2TPv3 control message types (see [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]) are listed for
reference.
SCCRQ L2TPv3 Start-Control-Connection-Request control message
SCCRP L2TPv3 Start-Control-Connection-Reply control message
SCCCN L2TPv3 Start-Control-Connection-Connected control message
StopCCN L2TPv3 Stop-Control-Connection-Notification control message
ICRQ L2TPv3 Incoming-Call-Request control message
ICRP L2TPv3 Incoming-Call-Reply control message
ICCN L2TPv3 Incoming-Call-Connected control message
OCRQ L2TPv3 Outgoing-Call-Request control message
OCRP L2TPv3 Outgoing-Call-Reply control message
OCCN L2TPv3 Outgoing-Call-Connected control message
CDN L2TPv3 Call-Disconnect-Notify control message
SLI L2TPv3 Set-Link-Info control message
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>. Requirements</span>
An Ethernet PW emulates a single Ethernet link between exactly two
endpoints. The following figure depicts the PW termination relative
to the NSP and PSN tunnel within an LCCE [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>]. The Ethernet
interface may be connected to one or more Remote Systems (an L2TPv3
Remote System is referred to as Customer Edge (CE) in this and
associated PWE3 documents). The LCCE may or may not be a PE.
+---------------------------------------+
| LCCE |
+-+ +-----+ +------+ +------+ +-+
|P| | | |PW ter| | PSN | |P|
Ethernet <==>|h|<=>| NSP |<=>|minati|<=>|Tunnel|<=>|h|<==> PSN
Interface |y| | | |on | | | |y|
+-+ +-----+ +------+ +------+ +-+
| |
+---------------------------------------+
Figure 1: PW termination
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
The PW termination point receives untagged (also referred to as
'raw') or tagged Ethernet frames and delivers them unaltered to the
PW termination point on the remote LCCE. Hence, it can provide
untagged or tagged Ethernet link emulation service.
The "NSP" function includes packet processing needed to translate the
Ethernet frames that arrive at the CE-LCCE interface to/from the
Ethernet frames that are applied to the PW termination point. Such
functions may include stripping, overwriting, or adding VLAN tags.
The NSP functionality can be used in conjunction with local
provisioning to provide heterogeneous services where the CE-LCCE
encapsulations at the two ends may be different.
The physical layer between the CE and LCCE, and any adaptation (NSP)
functions between it and the PW termination, are outside of the scope
of PWE3 and are not defined here.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. PW Establishment</span>
With L2TPv3 as the tunneling protocol, Ethernet PWs are L2TPv3
sessions. An L2TP Control Connection has to be set up first between
the two LCCEs. Individual PWs can then be established as L2TP
sessions.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. LCCE-LCCE Control Connection Establishment</span>
The two LCCEs that wish to set up Ethernet PWs MUST establish an L2TP
Control Connection first as described in [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]. Hence, an
Ethernet PW Type must be included in the Pseudowire Capabilities List
as defined in [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]. The type of PW can be either "Ethernet
port" or "Ethernet VLAN". This indicates that the Control Connection
can support the establishment of Ethernet PWs. Note that there are
two Ethernet PW Types required. For connecting an Ethernet port to
another Ethernet port, the PW Type MUST be "Ethernet port"; for
connecting an Ethernet VLAN to another Ethernet VLAN, the PW Type
MUST be "Ethernet VLAN".
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. PW Session Establishment</span>
The provisioning of an Ethernet port or Ethernet VLAN and its
association with a PW triggers the establishment of an L2TP session
via the standard Incoming Call three-way handshake described in
<a href="./rfc3931#section-3.4.1">Section 3.4.1 of [RFC3931]</a>.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
Note that an L2TP Outgoing Call is essentially a method of
controlling the originating point of a Switched Virtual Circuit
(SVC), allowing it to be established from any reachable L2TP-enabled
device able to perform outgoing calls. The Outgoing Call model and
its corresponding OCRQ, OCRP, and OCCN control messages are mainly
used within the dial arena with L2TPv2 today and has not been found
applicable for PW applications yet.
The following are the signaling elements needed for the Ethernet PW
establishment:
a) Pseudowire Type: The type of a Pseudowire can be either "Ethernet
port" or "Ethernet VLAN". Each LCCE signals its Pseudowire type
in the Pseudowire Type AVP [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]. The assigned values for
"Ethernet port" and "Ethernet VLAN" Pseudowire types are captured
in the "IANA Considerations" of this document. The Pseudowire
Type AVP MUST be present in the ICRQ.
b) Pseudowire ID: Each PW is associated with a Pseudowire ID. The
two LCCEs of a PW have the same Pseudowire ID for it. The Remote
End Identifier AVP [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>] is used to convey the Pseudowire ID.
The Remote End Identifier AVP MUST be present in the ICRQ in order
for the remote LCCE to determine the PW to associate the L2TP
session with. An implementation MUST support a Remote End
Identifier of four octets known to both LCCEs either by manual
configuration or some other means. Additional Remote End
Identifier formats that MAY be supported are outside the scope of
this document.
c) The Circuit Status AVP [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>] MUST be included in ICRQ and ICRP
to indicate the circuit status of the Ethernet port or Ethernet
VLAN. For ICRQ and ICRP, the Circuit Status AVP MUST indicate
that the circuit status is for a new circuit (refer to N bit in
<a href="#section-2.3.3">Section 2.3.3</a>). An implementation MAY send an ICRQ or ICRP before
an Ethernet interface is ACTIVE, as long as the Circuit Status AVP
(refer to A bit in <a href="#section-2.3.3">Section 2.3.3</a>) in the ICRQ or ICRP reflects the
correct status of the Ethernet port or Ethernet VLAN link. A
subsequent circuit status change of the Ethernet port or Ethernet
VLAN MUST be conveyed in the Circuit Status AVP in ICCN or SLI
control messages. For ICCN and SLI (refer to <a href="#section-2.3.2">Section 2.3.2</a>), the
Circuit Status AVP MUST indicate that the circuit status is for an
existing circuit (refer to N bit in <a href="#section-2.3.3">Section 2.3.3</a>) and reflect the
current status of the link (refer to A bit in <a href="#section-2.3.3">Section 2.3.3</a>).
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. PW Session Monitoring</span>
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. Control Connection Keep-alive</span>
The working status of a PW is reflected by the state of the L2TPv3
session. If the corresponding L2TPv3 session is down, the PW
associated with it MUST be shut down. The Control Connection keep-
alive mechanism of L2TPv3 can serve as a link status monitoring
mechanism for the set of PWs associated with a Control Connection.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. SLI Message</span>
In addition to the Control Connection keep-alive mechanism of L2TPv3,
Ethernet PW over L2TP makes use of the Set-Link-Info (SLI) control
message defined in [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]. The SLI message is used to signal
Ethernet link status notifications between LCCEs. This can be useful
to indicate Ethernet interface state changes without bringing down
the L2TP session. Note that change in the Ethernet interface state
will trigger an SLI message for each PW associated with that Ethernet
interface. This may be one Ethernet port PW or more than one
Ethernet VLAN PW. The SLI message MUST be sent any time there is a
status change of any values identified in the Circuit Status AVP.
The only exception to this is the initial ICRQ, ICRP, and CDN
messages that establish and tear down the L2TP session itself. The
SLI message may be sent from either LCCE at any time after the first
ICRQ is sent (and perhaps before an ICRP is received, requiring the
peer to perform a reverse Session ID lookup).
<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>. Use of Circuit Status AVP for Ethernet</span>
Ethernet PW reports circuit status with the Circuit Status AVP
defined in [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]. For reference, this AVP is shown below:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Value is a 16-bit mask with the two least significant bits
defined and the remaining bits reserved for future use. Reserved
bits MUST be set to 0 when sending and ignored upon receipt.
The A (Active) bit indicates whether the Ethernet interface is ACTIVE
(1) or INACTIVE (0).
The N (New) bit indicates whether the circuit status is for a new (1)
Ethernet circuit or an existing (0) Ethernet circuit.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Packet Processing</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Encapsulation</span>
The encapsulation described in this section refers to the
functionality performed by the PW termination point depicted in
Figure 1, unless otherwise indicated.
The entire Ethernet frame, without the preamble or frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE. This is done regardless of whether or
not a VLAN tag is present in the Ethernet frame. For Ethernet port-
to-port mode, the remote LCCE simply decapsulates the L2TP payload
and sends it out on the appropriate interface without modifying the
Ethernet header. For Ethernet VLAN-to-VLAN mode, the remote LCCE MAY
rewrite the VLAN tag. As described in <a href="#section-1">Section 1</a>, the VLAN tag
modification is an NSP function.
The Ethernet PW over L2TP is homogeneous with respect to packet
encapsulation, i.e., both ends of the PW are either untagged or
tagged. The Ethernet PW can still be used to provide heterogeneous
services using NSP functionality at the ingress and/or egress LCCE.
The definition of such NSP functionality is outside the scope of this
document.
The maximum length of the Ethernet frame carried as the PW payload is
irrelevant as far as the PW is concerned. If anything, that value
would only be relevant when quantifying the faithfulness of the
emulation.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Sequencing</span>
Data packet sequencing MAY be enabled for Ethernet PWs. The
sequencing mechanisms described in [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>] MUST be used for
signaling sequencing support.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. MTU Handling</span>
With L2TPv3 as the tunneling protocol, the IP packet resulting from
the encapsulation is M + N bytes longer than the Ethernet frame
without the preamble or FCS. Here M is the length of the IP header
along with associated options and extension headers, and the value of
N depends on the following fields:
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
L2TP Session Header:
Flags, Ver, Res - 4 octets (L2TPv3 over UDP only)
Session ID - 4 octets
Cookie Size - 0, 4, or 8 octets
L2-Specific Sublayer - 0 or 4 octets (i.e., using sequencing)
Hence the range for N in octets is:
N = 4-16, for L2TPv3 data messages over IP;
N = 16-28, for L2TPv3 data messages over UDP;
(N does not include the IP header).
Fragmentation in the PSN can occur when using Ethernet over L2TP,
unless proper configuration and management of MTU sizes are in place
between the Customer Edge (CE) router and Provider Edge (PE) router,
and across the PSN. This is not specific only to Ethernet over
L2TPv3, and the base L2TPv3 specification [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>] provides general
recommendations with respect to fragmentation and reassembly in
<a href="#section-4.1.4">Section 4.1.4</a>. "PWE3 Fragmentation and Reassembly" [<a href="./rfc4623" title=""Pseudowire Emulation Edge-to- Edge (PWE3) Fragmentation and Reassembly"">RFC4623</a>]
expounds on this topic, including a fragmentation and reassembly
mechanism within L2TP itself in the event that no other option is
available. Implementations MUST follow these guidelines with respect
to fragmentation and reassembly.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Applicability Statement</span>
The Ethernet PW emulation allows a service provider to offer a
"port-to-port"-based Ethernet service across an IP Packet Switched
Network (PSN), while the Ethernet VLAN PW emulation allows an "VLAN-
to-VLAN"-based Ethernet service across an IP Packet Switched Network
(PSN).
The Ethernet or Ethernet VLAN PW emulation has the following
characteristics in relationship to the respective native service:
o Ethernet PW connects two Ethernet port ACs, and Ethernet VLAN PW
connects two Ethernet VLAN ACs, which both support bi-directional
transport of variable-length Ethernet frames. The ingress LCCE
strips the preamble and FCS from the Ethernet frame and transports
the frame in its entirety across the PW. This is done regardless
of the presence of the VLAN tag in the frame. The egress LCCE
receives the Ethernet frame from the PW and regenerates the
preamble and FCS before forwarding the frame to the attached
Remote System (see <a href="#section-3.1">Section 3.1</a>). Since FCS is not being
transported across either Ethernet or Ethernet VLAN PWs, payload
integrity transparency may be lost. To achieve payload integrity
transparency on Ethernet or Ethernet VLAN PWs using L2TP over IP
or L2TP over UDP/IP, the L2TPv3 session can utilize IPsec as
specified in <a href="./rfc3931#section-4.1.3">Section 4.1.3 of [RFC3931]</a>.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
o While architecturally [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>] outside the scope of the L2TPv3 PW
itself, if VLAN tags are present, the NSP may rewrite VLAN tags on
ingress or egress from the PW (see <a href="#section-3.1">Section 3.1</a>).
o The Ethernet or Ethernet VLAN PW only supports homogeneous
Ethernet frame type across the PW; both ends of the PW must be
either tagged or untagged. Heterogeneous frame type support
achieved with NSP functionality is outside the scope of this
document (see <a href="#section-3.1">Section 3.1</a>).
o Ethernet port or Ethernet VLAN status notification is provided
using the Circuit Status AVP in the SLI message (see Sections
2.3.2 and 2.3.3). Loss of connectivity between LCCEs can be
detected by the L2TPv3 keep-alive mechanism (see <a href="#section-2.3.1">Section 2.3.1</a> of
this document and <a href="./rfc3931#section-4.4">Section 4.4 of [RFC3931]</a>). The LCCE can convey
these indications back to its attached Remote System.
o The maximum frame size that can be supported is limited by the PSN
MTU minus the L2TPv3 header size, unless fragmentation and
reassembly is used (see <a href="#section-3.3">Section 3.3</a> of this document and <a href="./rfc3931#section-4.1.4">Section</a>
<a href="./rfc3931#section-4.1.4">4.1.4 of [RFC3931]</a>).
o The Packet Switched Network may reorder, duplicate, or silently
drop packets. Sequencing may be enabled in the Ethernet or
Ethernet VLAN PW for some or all packets to detect lost,
duplicate, or out-of-order packets on a per-session basis (see
<a href="#section-3.2">Section 3.2</a>).
o The faithfulness of an Ethernet or Ethernet VLAN PW may be
increased by leveraging Quality-of-Service (QoS) features of the
LCCEs and the underlying PSN. For example, for Ethernet 802.1Q
[<a href="#ref-802.1Q" title=""IEEE standard for local and metropolitan area networks virtual bridged local area networks"">802.1Q</a>] VLAN transport, the ingress LCCE MAY consider the user
priority field (i.e., 802.1p) of the VLAN tag for traffic
classification and QoS treatments, such as determining the
Differentiated Services (DS) field [<a href="./rfc2474" title=""Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"">RFC2474</a>] of the encapsulating
IP header. Similarly, the egress LCCE MAY consider the DS field
of the encapsulating IP header when rewriting the user priority
field of the VLAN tag or queuing the Ethernet frame before
forwarding the frame to the Remote System. The mapping between
the user priority field and the IP header DS field as well as the
Quality-of-Service model deployed are application specific and are
outside the scope of this document.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Congestion Control</span>
As explained in [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>], the PSN carrying the PW may be subject to
congestion, with congestion characteristics depending on PSN type,
network architecture, configuration, and loading. During congestion,
the PSN may exhibit packet loss that will impact the service carried
by the Ethernet or Ethernet VLAN PW. In addition, since Ethernet or
Ethernet VLAN PWs carry a variety of services across the PSN,
including but not restricted to TCP/IP, they may or may not behave in
a TCP-friendly manner prescribed by [<a href="./rfc2914" title=""Congestion Control Principles"">RFC2914</a>] and thus consume more
than their fair share.
Whenever possible, Ethernet or Ethernet VLAN PWs should be run over
traffic-engineered PSNs providing bandwidth allocation and admission
control mechanisms. IntServ-enabled domains providing the Guaranteed
Service (GS) or DiffServ-enabled domains using EF (expedited
forwarding) are examples of traffic-engineered PSNs. Such PSNs will
minimize loss and delay while providing some degree of isolation of
the Ethernet or Ethernet VLAN PW's effects from neighboring streams.
LCCEs SHOULD monitor for congestion (by using explicit congestion
notification or by measuring packet loss) in order to ensure that the
service using the Ethernet or Ethernet VLAN PW may be maintained.
When severe congestion is detected (for example, when enabling
sequencing and detecting that the packet loss is higher than a
threshold), the Ethernet or Ethernet VLAN PW SHOULD be halted by
tearing down the L2TP session via a CDN message. The PW may be
restarted by manual intervention or by automatic means after an
appropriate waiting time. Note that the thresholds and time periods
for shutdown and possible automatic recovery need to be carefully
configured. This is necessary to avoid loss of service due to
temporary congestion and to prevent oscillation between the congested
and halted states.
This specification offers no congestion control and is not TCP
friendly [<a href="#ref-TFRC" title=""TCP Friendly Rate Control (TFRC): Protocol Specification"">TFRC</a>]. Future works for PW congestion control (being
studied by the PWE3 Working Group) will provide congestion control
for all PW types including Ethernet and Ethernet VLAN PWs.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Ethernet over L2TPv3 is subject to all of the general security
considerations outlined in [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>].
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
The signaling mechanisms defined in this document rely upon the
following Ethernet Pseudowire Types (see Pseudowire Capabilities List
as defined in 5.4.3 of [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>] and L2TPv3 Pseudowire Types in 10.6
of [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]), which were allocated by the IANA (number space created
as part of publication of [<a href="./rfc3931" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">RFC3931</a>]):
Pseudowire Types
----------------
0x0004 Ethernet VLAN Pseudowire Type
0x0005 Ethernet Pseudowire Type
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Contributors</span>
The following is the complete list of contributors to this document.
Rahul Aggarwal
Juniper Networks
Xipeng Xiao
Riverstone Networks
W. Mark Townsley
Stewart Bryant
Maria Alice Dos Santos
Cisco Systems
Cheng-Yin Lee
Alcatel
Tissa Senevirathne
Consultant
Mitsuru Higashiyama
Anritsu Corporation
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
This RFC evolved from the document, "Ethernet Pseudo Wire Emulation
Edge-to-Edge". We would like to thank its authors, T.So, X.Xiao, L.
Anderson, C. Flores, N. Tingle, S. Khandekar, D. Zelig and G. Heron
for their contribution. We would also like to thank S. Nanji, the
author of "Ethernet Service for Layer Two Tunneling Protocol", for
writing the first Ethernet over L2TP document.
Thanks to Carlos Pignataro for providing a thorough review and
helpful input.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC3931">RFC3931</a>] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", <a href="./rfc3931">RFC 3931</a>, March 2005.
[<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-RFC4623">RFC4623</a>] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", <a href="./rfc4623">RFC 4623</a>,
August 2006.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RFC3985">RFC3985</a>] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>, March 2005.
[<a id="ref-RFC2914">RFC2914</a>] Floyd, S., "Congestion Control Principles", <a href="https://www.rfc-editor.org/bcp/bcp41">BCP 41</a>, <a href="./rfc2914">RFC</a>
<a href="./rfc2914">2914</a>, September 2000.
[<a id="ref-RFC2474">RFC2474</a>] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>, December
1998.
[<a id="ref-802.3">802.3</a>] IEEE, "IEEE std 802.3 -2005/Cor 1-2006 IEEE Standard for
Information Technology - Telecommuincations and
Information Exchange Between Systems - Local and
Metropolitan Area Networks", IEEE Std 802.3-2005/Cor
1-2006 (Corrigendum to IEEE Std 802.3-2005)
[<a id="ref-802.1Q">802.1Q</a>] IEEE, "IEEE standard for local and metropolitan area
networks virtual bridged local area networks", IEEE Std
802.1Q-2005 (Incorporates IEEE Std 802.1Q1998, IEEE Std
802.1u-2001, IEEE Std 802.1v-2001, and IEEE Std 802.1s-
2002)
[<a id="ref-802.1ad">802.1ad</a>] IEEE, "IEEE Std 802.1ad - 2005 IEEE Standard for Local and
metropolitan area networks - virtual Bridged Local Area
Networks, Amendment 4: Provider Bridges", IEEE Std
802.1ad-2005 (Amendment to IEEE Std 8021Q-2005)
[<a id="ref-TFRC">TFRC</a>] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", <a href="./rfc3448">RFC</a>
<a href="./rfc3448">3448</a>, January 2003.
<span class="grey">Aggarwal, 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="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089
EMail: rahul@juniper.net
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: mark@townsley.net
Maria Alice Dos Santos
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
EMail: mariados@cisco.com
<span class="grey">Aggarwal, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4719">RFC 4719</a> Transport of Ethernet Frames over L2TPv3 November 2006</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Aggarwal, et al. Standards Track [Page 14]
</pre>
|
