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>Internet Engineering Task Force (IETF) L. Martini
Request for Comments: 6478 G. Swallow
Updates: <a href="./rfc5885">5885</a> G. Heron
Category: Standards Track Cisco
ISSN: 2070-1721 M. Bocci
Alcatel-Lucent
May 2012
<span class="h1">Pseudowire Status for Static Pseudowires</span>
Abstract
This document specifies a mechanism to signal Pseudowire (PW) status
messages using a PW associated channel (ACh). Such a mechanism is
suitable for use where no PW dynamic control plane exits, known as
static PWs, or where a Terminating Provider Edge (T-PE) needs to send
a PW status message directly to a far-end T-PE. The mechanism allows
PW Operations, Administration, and Maintenance (OAM) message mapping
and PW redundancy to operate on static PWs. This document also
updates <a href="./rfc5885">RFC 5885</a> in the case when Bi-directional Forwarding Detection
(BFD) is used to convey PW status-signaling information.
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/rfc6478">http://www.rfc-editor.org/info/rfc6478</a>.
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
Copyright Notice
Copyright (c) 2011 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Specification of Requirements ...................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Applicability ...................................................<a href="#page-3">3</a>
<a href="#section-5">5</a>. Pseudowire Status Operation .....................................<a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. PW OAM Message .............................................<a href="#page-4">4</a>
<a href="#section-5.2">5.2</a>. Sending a PW Status Message ................................<a href="#page-5">5</a>
<a href="#section-5.3">5.3</a>. PW OAM Status Message Transmit and Receive .................<a href="#page-6">6</a>
<a href="#section-5.3.1">5.3.1</a>. Acknowledgment of PW Status .........................<a href="#page-7">7</a>
<a href="#section-5.4">5.4</a>. MPLS Label Stack ...........................................<a href="#page-7">7</a>
<a href="#section-5.4.1">5.4.1</a>. Label Stack for a Message Destined to the Next PE ...<a href="#page-8">8</a>
5.4.2. Label Stack for a Message Destined to the Egress PE .8
<a href="#section-5.5">5.5</a>. S-PE Bypass Mode ...........................................<a href="#page-8">8</a>
<a href="#section-5.5.1">5.5.1</a>. S-PE Bypass Mode LDP Flag Bit .......................<a href="#page-9">9</a>
<a href="#section-6">6</a>. S-PE Operation .................................................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Static PW to Another Static PW ............................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Dynamic PW to Static PW or Vice Versa .....................<a href="#page-10">10</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-11">11</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-11">11</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-12">12</a>
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The default control plane for Pseudowire (PW) technology, as defined
in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], is based on the Label Distribution Protocol (LDP).
However, that document also describes a static provisioning mode
without a control plane. When a static PW is used, there is no
method to transmit the status of the PW or attachment circuit (AC)
between the two Provider Edge (PE) devices at each end of the PW.
This document defines a method to transport the PW status codes
defined in <a href="./rfc4447#section-5.4.2">Section 5.4.2 of [RFC4447]</a> and elsewhere [<a href="#ref-REDUNDANCY" title=""Pseudowire Preferential Forwarding Status Bit"">REDUNDANCY</a>] in-
band with the PW data using a generic associated channel [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Specification of Requirements</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" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
ACh: Associated Channel
ACH: Associated Channel Header
FEC: Forwarding Equivalence Class
LDP: Label Distribution Protocol
LSP: Label Switching Path
MS-PW: Multi-Segment Pseudowire
PE: Provider Edge
PW: Pseudowire
SS-PW: Single-Segment Pseudowire
S-PE: Switching Provider Edge Node of MS-PW
T-PE: Terminating Provider Edge Node of MS-PW
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Applicability</span>
As described in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and [<a href="./rfc6310" title=""Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping"">RFC6310</a>], a PE that establishes an
MPLS PW using means other than LDP, e.g., by static configuration,
MUST support some alternative method of status reporting. The
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
procedures described in this document are for use when PWs are
statically configured and an LDP control plane is not available.
As defined in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], a PE that establishes a PW using LDP MUST
use the PW status TLV mechanism for AC and PW status and defect
notification on that PW. In order to avoid duplicate notifications
and potentially conflicting notifications, such PEs MUST NOT use the
mechanisms described in this document for those PWs, except that the
S-PE bypass mode described in <a href="#section-5.5">Section 5.5</a> MAY be used when both T-PEs
at each end of the PW use LDP to establish the PW.
In order to protect against duplicate notifications and potentially
conflicting notifications, when the Pseudowire Status protocol for
Static Pseudowires described in this document is used, the BFD VCCV
(Virtual Circuit Connectivity Verification) status-signaling
mechanisms described in [<a href="./rfc5885" title=""Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)"">RFC5885</a>] (CV Types 0x08 and 0x20) MUST NOT
be used. BFD VCCV for fault detection (CV types 0x04 and 0x10) MAY
still be used.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Pseudowire Status Operation</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. PW OAM Message</span>
The PW status TLV as defined in <a href="./rfc4447#section-5.4.2">Section 5.4.2 of [RFC4447]</a> is
transported in a PW OAM message using the PW ACH.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x0027 PW OAM Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Timer | TLV Length |A| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACh PW OAM Message Packet Header
The first 32 bits are the standard ACH header construct as defined in
[<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>].
The first nibble (0001b) indicates the ACH instead of PW data. The
version and the reserved values are both set to 0 as specified in
[<a href="./rfc4385" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">RFC4385</a>].
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
The refresh timer is an unsigned integer and specifies refresh time
in seconds with a range from 1 to 65535. The value 0 means that the
refresh timer is set to infinity, and the PW OAM message will never
be refreshed, and will never timeout.
The TLV length field indicates the length of all TLVs only. This
document defines only the transport of the PW status TLV, as defined
in <a href="#section-5.4.2">Section 5.4.2</a>, [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], in the TLV field. In the future,
additional TLVs may be defined to be used in this field with code
points allocated from the IANA registry called "LDP TLV Type Name
Space".
The A flag bit is used to indicate an acknowledgment of the PW status
TLV included. The rest of the flag bits are reserved and they MUST
be set to 0 on transmit, and ignored upon receipt. When the A bit is
set, the refresh timer value is a requested timer value.
The PW OAM Message code point value is 0x0027.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Sending a PW Status Message</span>
The PW Status messages are sent in-band using the PW OAM message
containing the PW Status TLV for a particular PW, as defined in
[<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>]. The PW Status TLV format is almost as defined in
[<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>] and is repeated here for the reader's convenience:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| PW Status (0x096A) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PW Status TLV Format
Unlike the case in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], here, the first 2 bits are reserved,
and MUST be set to zero on transmit and ignored on receipt.
The PW Status TLV is prepended with a PW OAM message header and sent
on the ACh of the PW to which the status update applies.
To clear a particular status indication, the PE needs to send a new
PW OAM message containing a PW Status TLV with the corresponding bit
cleared as defined in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>].
The procedures described in [<a href="./rfc6073" title=""Segmented Pseudowire"">RFC6073</a>] that apply to an S-PE and PW
using an LDP control plane also apply when sending PW status using
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
the PW OAM channel. The OPTIONAL procedures using the SP-PE TLV
described in [<a href="./rfc6073" title=""Segmented Pseudowire"">RFC6073</a>] can also be applied when sending PW status
using the PW OAM channel.
The detailed message transmit and message receive procedures are
specified in the next section. PW OAM status messages MUST NOT be
used as a connectivity verification method.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. PW OAM Status Message Transmit and Receive</span>
Unlike the PW status procedures defined in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], with this
method there is no TCP/IP session or session management. Therefore,
unlike the TCP/IP case, where each message is sent only once, the PW
OAM message containing the PW status TLV needs to be transmitted
repeatedly to ensure reliable message delivery. If a malformed TLV
or an unknown TLV is received in a PW OAM status message, the TLV
MUST be ignored, and the PE SHOULD report the event to the operator.
A PW OAM message containing a PW status TLV with a new status bit set
or reset will be transmitted immediately by the PE. Unless the
message is acknowledged within a second, the PW OAM message will then
be repeated twice more at an initial interval of one second.
Subsequently, the PW OAM message will be transmitted with an interval
specified by the refresh timer value in the packet. Note that this
value MAY be updated in the new PW OAM message packet, in which case
the new refresh timer value becomes the new packet transmit interval.
The suggested default value for the refresh timer is 600 seconds.
This default is adequate for typical deployments, and PEs are
designed to take into account processing these messages at the
required rate.
When a PW OAM message containing a status TLV is received, a timer is
started according to the refresh rate specified in the packet. If
another non-zero PW status message is not received within 3.5 times
the specified timer value, the status condition will timeout in 3.5
times the last refresh timer value received, and the default status
of zero is assumed on the PW. It is also a good practice to
introduce some jitter in the delay between refresh transmissions, as
long as the maximum jitter delay is within the prescribed maximum
refresh time of 3.5 times the specified timer value for 3 consecutive
refresh packets.
To clear a particular status fault, the PE need only send an updated
message with the corresponding bit cleared. If the PW status code is
zero, the PW OAM message will be sent like any other PW OAM status
message using the procedures described above; however, transmission
will cease after 3 PW status messages have been sent at one second
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
intervals and before the refresh timer expires. A PW status message
of zero MAY be acknowledged using the procedures described in <a href="#section-5.3.1">Section</a>
<a href="#section-5.3.1">5.3.1</a>. If it is acknowledged, then a timer value of zero MUST be
used. This SHOULD cause the PE sending the PW status notification
message with a PW status code equal to zero to stop sending and to
continue normal operation.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Acknowledgment of PW Status</span>
A PE receiving a PW OAM message containing a PW status message MAY
acknowledge the PW status message by simply building a reply packet
with the same format and status code as the received PW OAM message,
but with the A bit set, and transmitting it on the PW ACh back to the
source of the PW OAM message. The receiving PE MAY use the refresh
timer field in the acknowledgement packet to request a new refresh
interval from the originator of the PW OAM message. The timer value
set in the reply packet SHOULD then be used by the originator of the
PW OAM message as the new transmit interval. If the requested
refresh timer value is to be used, then, when the the current timer
expires, the PW OAM message transmission interval is set to the new
value and the new value is sent in the PW OAM message. If the
transmitting PE does not want to use the new timer value (for local
policy reasons, or because it simply cannot support it), it MUST
refresh the PW OAM message with the timer value it desires. The
receiving PE will then set its timeout timer according to the new
refresh timer value that is in the packet received, regardless of
what timer value it requested. The receiving PE MUST NOT request a
new refresh timer value more than once per refresh interval.
The suggested default value for the refresh timer value in the
acknowledgment packet is 600 seconds.
If the sender PE receives an acknowledgment message that does not
match the current active PW status message being sent, it simply
ignores the acknowledgment packet.
If a PE that has received a non-zero status code for a PW detects by
any means that the far end PE has become unreachable, it will follow
the standard defect entry procedures of <a href="./rfc6310#section-6.2">[RFC6310], Section 6.2</a>.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. MPLS Label Stack</span>
With one exception, all PW OAM status messages are sent to the
adjacent PE across the PSN tunnel. In many cases, the transmitting
PE has no way to determine whether the adjacent PE is an S-PE or a
T-PE. This is a necessary behavior to preserve backward
compatibility with PEs that do not understand MS-PWs. In the
procedures described in this document, there are two possible
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
destinations for the PW OAM status messages: the adjacent PE or the
T-PE. Sending a PW status message directly to the T-PE is an
enhanced method that is only applicable using PW OAM status messages
sent in the PW ACH.
<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>. Label Stack for a Message Destined to the Next PE</span>
A PE that needs to forward a PW OAM status message to the adjacent PE
across the PSN tunnel MUST set the PW label TTL field to 1.
Furthermore, if the control word is not in use on the particular PW,
the PE MUST place the GAL reserved label [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>] below the PW label
with the TTL field set to 1.
<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>. Label Stack for a Message Destined to the Egress PE</span>
This is also known as "S-PE bypass mode"; see below. A T-PE that
requires sending a PW OAM status message directly to the
corresponding T-PE at the other end of the PW MUST set the TTL of the
PW label to a value that is sufficient to reach the corresponding
T-PE. This value will be greater than one, but will be set according
to the local policy on the transmitting T-PE. Furthermore, if the
control word is not in use on the particular PW, the PE MUST also
place the GAL reserved label [<a href="./rfc5586" title=""MPLS Generic Associated Channel"">RFC5586</a>] below the PW label with the
TTL field set to 1.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. S-PE Bypass Mode</span>
S-PE bypass mode enables a T-PE that uses LDP as the PW setup and
control protocol to bypass all S-PEs that might be present along the
MS-PW and to send a message directly to the remote T-PE. This is
used for very fast message transmission in-band with the PW PDUs.
This mode is OPTIONAL and MUST be supported by both T-PEs to be
enabled. This mode MUST NOT be used if the first PW segment
connected to each T-PE is not using LDP.
Note that this method MUST NOT be used to send messages that are
permitted to originate at an S-PE. Otherwise, race conditions could
occur between messages sent via the control plane by S-PEs and
messages sent via the data plane by T-PEs.
Status codes, except for those listed below, MUST NOT be sent using
the S-PE bypass procedure and MUST be ignored on reception.
0x00000002 - Local Attachment Circuit (ingress) Receive Fault
0x00000004 - Local Attachment Circuit (egress) Transmit Fault
0x00000020 - PW forwarding standby
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
0x00000040 - Request switchover to this PW
Note that since "clear all failures" may be sent by an S-PE, it MUST
NOT be sent using the S-PE bypass mode.
When S-PE bypass mode is enabled, all PW Status TLVs received using
this method have priority over PW Status TLVs sent via control
protocols such as LDP [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>]. However, the same PW Status TLVs
MUST also be sent in LDP to keep the S-PEs state updated.
<span class="h4"><a class="selflink" id="section-5.5.1" href="#section-5.5.1">5.5.1</a>. S-PE Bypass Mode LDP Flag Bit</span>
When a PW Segment along an MS-PW is using the LDP control protocol
and wishes to request the use of the S-PE bypass status message mode,
it sets the B bit in the generic protocol flags interface parameters
sub-TLV as shown in Figure 3. This flag can only be set by a T-PE
using LDP as the PW configuration and management protocol. If the
S-PE bypass mode LDP flag bit in the generic protocol flags interface
parameter does not match in the FEC advertisement for directions of a
specific PW, that PW MUST NOT be enabled.
The interface parameter is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x18 | Length=4 |R R R R R R R R R R R R R R R B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Generic Protocol Flags Sub-TLV
TLV Type
Type 0x18 - PW Generic Protocol Flags.
Length
TLV length is always 4 octets.
Flags
Bit B, in position 31 above, is set to request the S-PE bypass
mode. R bits are to be allocated by IANA as described in the IANA
section. If they are not allocated, they are to be considered as
reserved for future use and MUST be zero on transmission and
ignored on reception of this TLV.
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
If the T-PE receives an LDP label mapping message containing a
generic protocol flags interface parameter TLV with the bit B set,
then the T-PE receiving the label mapping message MAY send S-PE
bypass status messages in the PW ACh. If bit B of said TLV is not
set, or the TLV is not present, then the T-PE receiving the label
mapping message MUST NOT send S-PE bypass status messages in the
PW ACh.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. S-PE Operation</span>
The S-PE will operate according to the procedures defined in
[<a href="./rfc6073" title=""Segmented Pseudowire"">RFC6073</a>]. The following additional procedures apply to the case
where a static PW segment is switched to a dynamic PW segment that
uses LDP, and the case where a static PW segment is switched to
another static PW segment.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Static PW to Another Static PW</span>
The procedures that are described in <a href="./rfc6073#section-10">[RFC6073] Section 10</a> also apply
to the case of a static PW switched to another static PW. The LDP
header is simply replaced by the PW OAM header; otherwise, the packet
format will be identical. The information that is necessary to form
an SP-PE TLV MUST be configured in the S-PE, or no SP-PE TLV will be
sent. [<a href="./rfc6073" title=""Segmented Pseudowire"">RFC6073</a>] defines the IANA "Pseudowire Switching Point PE TLV
Type" registry. In order to support the static PW configuration and
addressing scheme, the following new code point has been assigned:
Type Length Description
---- ------ -----------
0x07 24 Static PW/MPLS-TP PW segment ID of last
PW segment traversed
The format of this TLV is that of the "Static Pseudowire Sub-TLV"
defined in [<a href="./rfc6426" title=""MPLS On-Demand Connectivity Verification and Route Tracing"">RFC6426</a>].
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Dynamic PW to Static PW or Vice Versa</span>
The procedures that are described in <a href="./rfc6073#section-10">Section 10 of [RFC6073]</a> also
apply to this situation. However, if the PW label of the LDP-
controlled PW segment is withdrawn by the adjacent PE, the S-PE will
set the PW status code "0x00000001 - Pseudowire Not Forwarding" to
the adjacent PW on the static PW segment.
The S-PE will only withdraw its label for the dynamic, LDP-controlled
PW segment if the S-PE is not provisioned.
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The security measures described in [<a href="./rfc4447" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">RFC4447</a>], [<a href="./rfc5085" title=""Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires"">RFC5085</a>], and
[<a href="./rfc6073" title=""Segmented Pseudowire"">RFC6073</a>] are adequate for the proposed mechanism.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
IANA has set up the registry of "PW Generic Protocol Flags". These
are bit strings of length 16. Bit 0 is defined in this document.
Bits 1 through 15 are to be assigned by IANA using the "IETF Review"
policy defined in [<a href="./rfc5226" title="">RFC5226</a>].
Any requests for allocation from this registry require a description
of up to 65 characters.
Initial PW Generic Protocol Flags value allocations are as follows:
Bit Mask Description
====================================================================
0x0001 - S-PE bypass mode [<a href="./rfc6478">RFC6478</a>]
This document uses a new Associated Channel Type. IANA already
maintains the "Pseudowire Associated Channel Types" registry. The
value 0x0027 has been assigned with the description "PW OAM Message".
This document uses a new Pseudowire Switching Point PE TLV Type.
IANA already maintains the "Pseudowire Switching Point PE sub-TLV
Type" registry. A value of 0x07 has been assigned with the
description "Static PW/MPLS-TP PW segment ID of last PW segment
traversed".
This document uses a new interface parameter type. IANA already
maintains the "Pseudowire Interface Parameters Sub-TLV type
Registry". A value of 0x18 has been assigned with the description
"PW Generic Protocol Flags".
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.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-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.
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
[<a id="ref-RFC4447">RFC4447</a>] Martini, L., Ed., 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-RFC5085">RFC5085</a>] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", <a href="./rfc5085">RFC 5085</a>, December
2007.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC6073">RFC6073</a>] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", <a href="./rfc6073">RFC 6073</a>, January
2011.
[<a id="ref-RFC6310">RFC6310</a>] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
Nadeau, T., and Y(J). Stein, "Pseudowire (PW)
Operations, Administration, and Maintenance (OAM)
Message Mapping", <a href="./rfc6310">RFC 6310</a>, July 2011.
[<a id="ref-RFC6426">RFC6426</a>] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal,
"MPLS On-Demand Connectivity Verification and Route
Tracing", <a href="./rfc6426">RFC 6426</a>, November 2011.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-REDUNDANCY">REDUNDANCY</a>] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", Work in Progress,
September 2011.
[<a id="ref-RFC5885">RFC5885</a>] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV)", <a href="./rfc5885">RFC 5885</a>,
June 2010.
[<a id="ref-RFC5586">RFC5586</a>] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", <a href="./rfc5586">RFC 5586</a>, June 2009.
<span class="grey">Martini, 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="./rfc6478">RFC 6478</a> Pseudowire Status for Static Pseudowires May 2012</span>
Authors' Addresses
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
George Swallow
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
United States
EMail: swallow@cisco.com
Giles Heron
Cisco Systems
9-11 New Square
Bedfont Lakes
Feltham
Middlesex
TW14 8HA
United Kingdom
EMail: giheron@cisco.com
Matthew Bocci
Alcatel-Lucent
Voyager Place
Shoppenhangers Road
Maidenhead
Berks
SL6 2PJ
United Kingdom
EMail: matthew.bocci@alcatel-lucent.com
Martini, et al. Standards Track [Page 13]
</pre>
|
