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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) S. Bryant, Ed.
Request for Comments: 6658 L. Martini
Category: Standards Track G. Swallow
ISSN: 2070-1721 Cisco Systems
A. Malis
Verizon Communications
July 2012
<span class="h1">Packet Pseudowire Encapsulation over an MPLS PSN</span>
Abstract
This document describes a pseudowire mechanism that is used to
transport a packet service over an MPLS PSN in the case where the
client Label Switching Router (LSR) and the server Provider Edge
equipments are co-resident in the same equipment. This pseudowire
mechanism may be used to carry all of the required layer 2 and layer
3 protocols between the pair of client LSRs.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6658">http://www.rfc-editor.org/info/rfc6658</a>.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Network Reference Model . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Client Network-Layer Model . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Ethernet and IEEE 802.1 Functional Restrictions . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Congestion Considerations . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-10">10</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#appendix-A">Appendix A</a>. Encapsulation Approaches Considered . . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A.1">A.1</a>. A Protocol Identifier in the Control Word . . . . . . . . <a href="#page-11">11</a>
<a href="#appendix-A.2">A.2</a>. PID Label . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A.3">A.3</a>. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.4">A.4</a>. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.5">A.5</a>. Recommended Encapsulation . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
There is a need to provide a method of carrying a packet service over
an MPLS PSN in a way that provides isolation between the two
networks. The server MPLS network may be an MPLS network or a
network conforming to the MPLS Transport Profile (MPLS-TP) [<a href="./rfc5317" title=""Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile"">RFC5317</a>].
The client may also be either an MPLS network or a network conforming
to the MPLS-TP. Considerations regarding the use of an MPLS network
as a server for an MPLS-TP network are outside the scope of this
document.
Where the client equipment is connected to the server equipment via a
physical interface, the same data-link type must be used to attach
the clients to the Provider Edge (PE) equipments, and a pseudowire
(PW) of the same type as the data-link must be used [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>]. The
reason that interworking between different physical and data-link
attachment types is specifically disallowed in the pseudowire
architecture is because this is a complex task and not a simple bit-
mapping exercise. The interworking is not limited to the physical
and data-link interfaces and the state-machines. It also requires a
compatible approach to the formation of the adjacencies between
attached client network equipment. As an example, the reader should
consider the differences between router adjacency formation on a
point-to-point link compared to a multipoint-to-multipoint interface
(e.g., Ethernet).
A further consideration is that two adjacent MPLS Label Switching
Routers (LSRs) do not simply exchange MPLS packets. They exchange IP
packets for adjacency formation, control, routing, label exchange,
management, and monitoring purposes. In addition, they may exchange
data-link packets as part of routing (e.g., IS-IS Hellos and IS-IS
Link State Packets) and for Operations, Administration, and
Maintenance (OAM) purposes such as the Link-Layer Discovery Protocol
[<a href="#ref-IEEE.802.1AB.2009">IEEE.802.1AB.2009</a>]. Thus, the two clients require an attachment
mechanism that can be used to multiplex a number of protocols. In
addition, it is essential to the correct operation of the network
layer that all of these protocols fate share.
Where the client LSR and server PE are co-located in the same
equipment, the data-link layer can be simplified to a point-to-point
Ethernet used to multiplex the various data-link types onto a
pseudowire. This is the method described in this document.
<a href="#appendix-A">Appendix A</a> provides information on alternative approaches to
providing a packet PW that were considered by the PWE3 Working Group
and the reasons for using the method defined in this specification.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
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">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Network Reference Model</span>
The network reference model for the packet pseudowire operating in an
MPLS network is shown in Figure 1. This is an extension of Figure 3
"Pre-processing within the PWE3 Network Reference Model" from
[<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>].
PW PW
End Service End Service
| |
|<------- Pseudowire ------->|
| |
| Server |
| |<- PSN Tunnel ->| |
| V V |
------- +-----+-----+ +-----+-----+ -------
) | | |================| | | (
Client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client
MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN
) | | | | | | (
) | | |================| | | (
------- +-----+-----+ +-----+-----+ --------
^ ^
| |
| |
|<---- Emulated Service----->|
| |
Virtual physical Virtual physical
termination termination
Figure 1: Packet PW Network Reference Model
In this model, the LSRs (LSR1 and LSR2) are part of the client MPLS
PSN. The PEs (PE1 and PE2) are part of the server PSN that is to be
used to provide connectivity between the client LSRs. The attachment
circuit that is used to connect the MPLS LSRs to the PEs is a virtual
interface within the equipment. A packet pseudowire is used to
provide connectivity between these virtual interfaces. This packet
pseudowire is used to transport all of the required layer 2 and layer
3 protocols between LSR1 and LSR2.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Client Network-Layer Model</span>
The packet PW appears as a single point-to-point link to the client
layer. Network-layer adjacency formation and maintenance between the
client equipments will follow the normal practice needed to support
the required relationship in the client layer. The assignment of
metrics for this point-to-point link is a matter for the client
layer. In a hop-by-hop routing network, the metrics would normally
be assigned by appropriate configuration of the embedded client
network-layer equipment (e.g., the embedded client LSR). Where the
client was using the packet PW as part of a traffic-engineered path,
it is up to the operator of the client network to ensure that the
server-layer operator provides the necessary service-level agreement.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Forwarding Model</span>
The packet PW forwarding model is illustrated in Figure 2. The
forwarding operation can be likened to a virtual private network
(VPN), in which a forwarding decision is first taken at the client
layer, an encapsulation is applied, and then a second forwarding
decision is taken at the server layer.
+------------------------------------------------+
| |
| +--------+ +--------+ |
| | | Pkt +-----+ | | |
------+ +---------+ PW1 +--------+ +------
| | Client | AC +-----+ | Server | |
Client | | LSR | | LSR | | Server
Network | | | Pkt +-----+ | | | Network
------+ +---------+ PW2 +--------+ +------
| | | AC +-----+ | | |
| +--------+ +--------+ |
| |
+------------------------------------------------+
Figure 2: Packet PW Forwarding Model
A packet PW PE comprises three components: the client LSR, a PW
processor, and a server LSR. Note that [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>] does not formally
indicate the presence of the server LSR because it does not concern
itself with the server layer. However it is useful in this document
to recognize that the server LSR exists.
It may be useful to first recall the operation of a layer 2 PW such
as an Ethernet PW [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">RFC4448</a>] within this model. The client LSR is not
present, and packets arrive directly on the attachment circuit (AC)
that is part of the client network. The PW function undertakes any
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
header processing, if configured to do so; it then optionally pushes
the PW control word (CW) and finally pushes the PW label. The PW
function then passes the packet to the LSR function, which pushes the
label needed to reach the egress PE and forwards the packet to the
next hop in the server network. At the egress PE, the packet
typically arrives with the PW label at the top of the stack; the
packet is thus directed to the correct PW instance. The PW instance
performs any required reconstruction using, if necessary, the CW, and
the packet is sent directly to the attachment circuit.
Now let us consider the case of client-layer MPLS traffic being
carried over a packet PW. An LSR belonging to the client layer is
embedded within the PE equipment. This is a type of native service
processing element [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>]. The client LSR determines the next hop
in the client layer, and pushes the label needed by the next hop in
the client layer. It then encapsulates the packet in an Ethernet
header setting the Ethertype to MPLS, and the client LSR passes the
packet to the correct PW instance. The PW instance then proceeds as
defined for an Ethernet PW [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">RFC4448</a>] by optionally pushing the
control word, then pushing the PW label, and finally handing the
packet to the server-layer LSR for delivery to the egress PE in the
server layer.
At the egress PE in the server layer, the packet is first processed
by the server LSR, which uses the PW label to pass the packet to the
correct PW instance. This PW instance processes the packet as
described in [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">RFC4448</a>]. The resultant Ethernet encapsulated client
packet is then passed to the egress client LSR, which then processes
the packet in the normal manner.
Note that although the description above is written in terms of the
behavior of an MPLS LSR, the processing model would be similar for an
IP packet or any other protocol type.
Note that the semantics of the PW between the client LSRs is a point-
to-point link.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Packet PW Encapsulation</span>
The client network-layer packet encapsulation into a packet PW is
shown in Figure 3.
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| |
| Ethernet | 14 octets
| Header |
| +---------------+
| |
+---------------+---------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+-------------------------------+
Figure 3: Packet PW Encapsulation
This conforms to the PW protocols stack as defined in [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">RFC4448</a>]. The
protocol stack is unremarkable except to note that the stack does not
retain 32-bit alignment between the virtual Ethernet header and the
PW optional control word (or the PW label when the optional
components are not present in the PW header). This loss of 32 bits
of alignment is necessary to preserve backwards compatibility with
the Ethernet PW design [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">RFC4448</a>]
Ethernet Raw Mode (PW type 5) MUST be used for the packet PW.
The PEs MAY use a local Ethernet address for the Ethernet header used
to encapsulate the client network-layer packet or MAY use the special
Ethernet addresses "PacketPWEthA" or "PacketPWEthB" as described
below.
IANA has allocated two unicast Ethernet addresses [<a href="./rfc5342" title=""IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters"">RFC5342</a>] for use
with this protocol, referred to as "PacketPWEthA" and "PacketPWEthB".
Where [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] signaling is used to set up the PW, the LDP peers
numerically compare their IP addresses. The LDP PE with the higher-
value IP address will use PacketPWEthA, whilst the LDP peer with the
lower-value IP address uses PacketPWEthB.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
Where no signaling PW protocol is used, suitable Ethernet addresses
MUST be configured at each PE.
Although this PW represents a point-to-point connection, the use of a
multicast destination address in the Ethernet encapsulation is
REQUIRED by some client-layer protocols. Peers MUST be prepared to
handle a multicast destination address in the Ethernet encapsulation.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Ethernet and IEEE 802.1 Functional Restrictions</span>
The use of Ethernet as the encapsulation mechanism for traffic
between the server LSRs is a convenience based on the widespread
availability of existing hardware. In this application, there is no
requirement for any Ethernet feature other than its protocol
multiplexing capability. Thus, for example, a server LSR is not
required to implement the Ethernet OAM.
The use and applicability of VLANs, IEEE 802.1p, and IEEE 802.1Q
tagging between PEs is not supported.
Point-to-multipoint and multipoint-to-multipoint operation of the
virtual Ethernet is not supported.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Congestion Considerations</span>
A packet pseudowire is normally used to carry IP, MPLS and their
associated support protocols over an MPLS network. There are no
congestion considerations beyond those that ordinarily apply to an IP
or MPLS network. Where the packet protocol being carried is not IP
or MPLS and the traffic volumes are greater than that ordinarily
associated with the support protocols in an IP or MPLS network, the
congestion considerations developed for PWs apply [<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>]
[<a href="./rfc5659" title=""An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge"">RFC5659</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
The virtual Ethernet approach to packet PW introduces no new security
risks. A more detailed discussion of pseudowire security is given in
[<a href="./rfc3985" title=""Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture"">RFC3985</a>], [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], and [<a href="./rfc3916" title=""Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)"">RFC3916</a>].
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
IANA has allocated two Ethernet unicast addresses from "IANA Unicast
48-bit MAC Addresses".
Address Usage Reference
------------------- ---------------- ---------
00-00-5E-00-52-00 PacketPWEthA [<a href="./rfc6658">RFC6658</a>]
00-00-5E-00-52-01 PacketPWEthB [<a href="./rfc6658">RFC6658</a>]
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The authors acknowledge the contributions made to this document by
Sami Boutros, Giles Herron, Siva Sivabalan, and David Ward.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<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-RFC4447">RFC4447</a>] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April 2006.
[<a id="ref-RFC4448">RFC4448</a>] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", <a href="./rfc4448">RFC 4448</a>, April 2006.
[<a id="ref-RFC5342">RFC5342</a>] Eastlake, D., "IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters", <a href="https://www.rfc-editor.org/bcp/bcp141">BCP 141</a>, <a href="./rfc5342">RFC 5342</a>,
September 2008.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-IEEE.802.1AB.2009">IEEE.802.1AB.2009</a>]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks --
Station and Media Access Control Connectivity Discovery",
IEEE Standard 802.1AB, 2009.
[<a id="ref-RFC3031">RFC3031</a>] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", <a href="./rfc3031">RFC 3031</a>, January 2001.
[<a id="ref-RFC3916">RFC3916</a>] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", <a href="./rfc3916">RFC 3916</a>,
September 2004.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</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-RFC4385">RFC4385</a>] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", <a href="./rfc4385">RFC 4385</a>, February 2006.
[<a id="ref-RFC5317">RFC5317</a>] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a
Transport Profile", <a href="./rfc5317">RFC 5317</a>, February 2009.
[<a id="ref-RFC5659">RFC5659</a>] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", <a href="./rfc5659">RFC 5659</a>,
October 2009.
[<a id="ref-RFC5921">RFC5921</a>] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
<a href="./rfc5921">RFC 5921</a>, July 2010.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Encapsulation Approaches Considered</span>
A number of approaches to the design of a packet pseudowire (PW) were
investigated by the PWE3 Working Group and were discussed in IETF
meetings and on the PWE3 list. This section describes the approaches
that were analyzed and the technical issues that the authors took
into consideration in arriving at the approach described in the main
body of this document. This appendix is provided so that engineers
considering alternative optimizations can have access to the
rationale for the selection of the approach described in this
document.
In a typical network, there are usually no more that four network-
layer protocols that need to be supported: IPv4, IPv6, MPLS, and
Connectionless Network Service (CLNS). However, any solution needs
to be scalable to a larger number of protocols. The approaches
considered in this appendix all satisfy this minimum requirement but
vary in their ability to support larger numbers of network-layer
protocols.
Additionally, it is beneficial if the complete set of protocols
carried over the network in support of a set of CE peers fate share.
It is additionally beneficial if a single OAM session can be used to
monitor the behavior of this complete set. During the investigation,
various views were expressed as to where these benefits lay on the
scale from absolutely required to "nice to have", but in the end,
they were not a factor in reaching our conclusion.
Four candidate approaches were analyzed:
1. A protocol identifier (PID) in the PW control word (CW)
2. A PID label
3. Parallel PWs - one per protocol
4. Virtual Ethernet
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. A Protocol Identifier in the Control Word</span>
In this approach, a Protocol Identifier (PID) is included in the PW
control word (CW) by appending it to the generic control word
[<a href="./rfc4385" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">RFC4385</a>] to make a 6-byte CW (it was thought that this approach
would include 2 reserved bytes to provide 32-bit alignment, but then
this was optimized out). A variant of this is just to use a 2-byte
PID without a control word.
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
This is a simple approach and is basically a virtual PPP interface
without the PPP control protocol. This has a smaller MTU than, for
example, a virtual Ethernet would need; however, in forwarding terms,
it is not as simple as the PID label or multiple PW approaches
described next and may not be deployable on a number of existing
hardware platforms.
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. PID Label</span>
In this approach, the PID is indicated by including a label after the
PW label that indicates the protocol type, as shown in Figure 4.
+-------------------------------+
| Client |
| Network-Layer |
| Packet | n octets
| |
+-------------------------------+
| Optional Control Word | 4 octets
+-------------------------------+
| PID Label (S=1) | 4 octets
+-------------------------------+
| PW Label | 4 octets
+-------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (four octets per label)
+-------------------------------+
Figure 4: Encapsulation of a Pseudowire with
a Pseudowire Load-Balancing Label
In the PID label approach, a new Label Distribution Protocol (LDP)
Forwarding Equivalence Class (FEC) element is used to signal the
mapping between protocol type and the PID label. This approach
complies with [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>].
A similar approach to PID label is described in <a href="./rfc5921#section-3.4.5">Section 3.4.5 of
[RFC5921]</a>. In this case, when the client is a network-layer packet
service such as IP or MPLS, a service label and demultiplexer label
(which may be combined) are used to provide the necessary
identifications needed to carry this traffic over an LSP.
The authors surveyed the hardware designs produced by a number of
companies across the industry and concluded that whilst the approach
complies with the MPLS architecture, it may conflict with a number of
designers' interpretations of the existing MPLS architecture. This
led to concerns that the approach may result in unexpected
difficulties in the future. Specifically, there was an assumption in
many designs that a forwarding decision should be made on the basis
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
of a single label. Whilst the approach is attractive, it cannot be
supported by many commodity chip sets, and this would require new
hardware, which would increase the cost of deployment and delay the
introduction of a packet PW service.
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. Parallel PWs</span>
In this approach, one PW is constructed for each protocol type that
must be carried between the PEs. Thus, a complete packet PW would
consist of a bundle of PWs. This model would be very simple and
efficient from a forwarding point of view. The number of parallel
PWs required would normally be relatively small. In a typical
network, there are usually no more that four network-layer protocols
that need to be supported: IPv4, IPv6, MPLS, and CLNS. However, any
solution needs to be scalable to a larger number of protocols.
There are a number of serious downsides with this approach:
1. From an operational point of view, the lack of fate sharing
between the protocol types can lead to complex faults that are
difficult to diagnose.
2. There is an undesirable trade-off in the OAM related to the first
point. We would have to run an OAM on each PW and bind them
together, which leads to significant protocol and software
complexity and does not scale well. Alternatively, we would need
to run a single OAM session on one of the PWs as a proxy for the
others and then diagnose any more complex failures on a case-by-
case basis. To some extent, the issue of fate sharing between
protocols in the bundle (for example, the assumed fate sharing
between CLNS and IP in IS-IS) can be mitigated through the use of
Bidirectional Forwarding Detection (BFD).
3. The need to configure, manage, and synchronize the behavior of a
group of PWs as if they were a single PW leads to an increase in
control-plane complexity.
The Parallel PW mechanism is therefore an approach that simplifies
the forwarding plane, but only at a cost of a considerable increase
in other aspects of the design, in particular, operation of the PW.
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. Virtual Ethernet</span>
Using a virtual Ethernet to provide a packet PW would require PEs to
include a virtual (internal) Ethernet interface and then to use an
Ethernet PW [<a href="./rfc4448" title=""Encapsulation Methods for Transport of Ethernet over MPLS Networks"">RFC4448</a>] to carry the user traffic. This is
conceptually simple and can be implemented today without any further
standards action, although there are a number of applicability
<span class="grey">Bryant, 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="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
considerations that it are useful to bring to the attention of the
community.
Conceptually, this is a simple approach, and some deployed equipments
can already do this. However, the requirement to run a complete
Ethernet adjacency led us to conclude that there was a need to
identify a simpler approach. The packets encapsulated in an Ethernet
header have a larger MTU than the other approaches, although this is
not considered to be an issue on the networks needing to carry packet
PWs.
The virtual Ethernet mechanism was the first approach that the
authors considered, before the merits of the other approaches
appeared to make them more attractive. As we shall see below,
however, the other approaches were not without issues, and it appears
that the virtual Ethernet is the preferred approach to providing a
packet PW.
<span class="h3"><a class="selflink" id="appendix-A.5" href="#appendix-A.5">A.5</a>. Recommended Encapsulation</span>
The operational complexity and the breaking of fate-sharing
assumptions associated with the parallel PW approach would suggest
that this is not an approach that should be further pursued.
The PID label approach gives rise to the concerns that it will break
implicit behavioral and label-stack size assumptions in many
implementations. Whilst those assumptions may be addressed with new
hardware, this would delay the introduction of the technology to the
point where it is unlikely to gain acceptance in competition with an
approach that needs no new protocol design and is already supportable
on many existing hardware platforms.
The PID in the CW leads to the most compact protocol stack, is
simple, and requires minimal protocol work. However, it is a new
forwarding design and, apart from the issue of the larger packet
header and the simpler adjacency formation, offers no advantage over
the virtual Ethernet.
The above considerations bring us back to the virtual Ethernet, which
is a well-known protocol stack with a well-known (internal) client
interface. It is already implemented in many hardware platforms and
is therefore readily deployable. After considering a number of
initially promising alternatives, the authors conclude that the
simplicity and existing hardware make the virtual Ethernet approach
to the packet PW the most attractive solution.
<span class="grey">Bryant, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6658">RFC 6658</a> Packet PW July 2012</span>
Authors' Addresses
Stewart Bryant (editor)
Cisco Systems
250, Longwater, Green Park,
Reading, Berks RG2 6GB
UK
EMail: stbryant@cisco.com
Luca Martini
Cisco Systems
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
USA
EMail: lmartini@cisco.com
George Swallow
Cisco Systems
1414 Massachusetts Ave
Boxborough, MA 01719
USA
EMail: swallow@cisco.com
Andrew G. Malis
Verizon Communications
60 Sylvan Rd.
Waltham, MA 02451
USA
EMail: andrew.g.malis@verizon.com
Bryant, et al. Standards Track [Page 15]
</pre>
|
