idnits 2.17.1 draft-ietf-pwe3-static-pw-status-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2011) is 4797 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-on-demand-cv-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Luca Martini 3 Internet Draft George Swallow 4 Intended status: Standards Track Giles Heron 5 Expires: September 2, 2011 Cisco 7 Matthew Bocci 8 Alcatel-Lucent 10 March 2, 2011 12 Pseudowire Status for Static Pseudowires 14 draft-ietf-pwe3-static-pw-status-02.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 2, 2010 39 Abstract 41 This document specifies a mechanism to signal Pseudowire (PW) status 42 messages using an PW associated channel (ACh). Such a mechanism is 43 suitable for use where no PW dynamic control plane exits, known as 44 static PWs, or where a Terminating Provider Edge (T-PE) needs to send 45 a PW status message directly to a far end T-PE. The mechanism allows 46 PW OAM message mapping and PW redundancy to operate on static PWs. 48 Table of Contents 50 1 Specification of Requirements ........................ 2 51 2 Introduction ......................................... 3 52 3 Terminology .......................................... 3 53 4 Applicability ........................................ 3 54 5 Pseudowire Status Operation .......................... 4 55 5.1 PW OAM Message ....................................... 4 56 5.2 Sending a PW Status Message .......................... 5 57 5.3 PW OAM status message transmit and receive ........... 6 58 5.3.1 Acknowledge of PW status ............................. 6 59 5.3.2 Applicable PW status Bits ............................ 7 60 5.4 MPLS Label Stack ..................................... 7 61 5.4.1 Label stack for a message destined to the next PE .... 7 62 5.4.2 Label stack for a message destined to the egress PE .. 8 63 5.5 S-PE bypass mode ..................................... 8 64 5.5.1 S-PE bypass mode LDP flag bit ........................ 8 65 5.5.2 S-PE bypass mode negotiation procedure ............... 9 66 6 S-PE operation ....................................... 9 67 6.1 Static PW to another Static PW ....................... 10 68 6.2 Dynamic PW to Static PW or vice versa ................ 10 69 7 Security Considerations .............................. 10 70 8 IANA Considerations .................................. 10 71 9 References ........................................... 11 72 9.1 Normative References ................................. 11 73 9.2 Informative References ............................... 11 74 10 Author's Addresses ................................... 12 76 1. Specification of Requirements 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 The default control plane for Pseudowire (PW) technology, as defined 85 in [RFC4447], is based on LDP. However that document also describes a 86 static provisioning mode without control plane. When a static PW is 87 used, there is no method to transmit the status of the PW, or 88 attachment circuit (AC) between the two PEs at each end of the PW. 89 This document defines a method to transport the PW status codes 90 defined in [RFC4447], sec 5.4.2, and [REDUNDANCY] in-band with the PW 91 data using a generic associated channel [RFC5586]. 93 3. Terminology 95 FEC: Forwarding Equivalence Class 97 LDP: Label Distribution Protocol 99 LSP: Label Switching Path 101 MS-PW: Multi-Segment Pseudowire 103 PE: Provider Edge 105 PW: Pseudowire 107 SS-PW: Single-Segment Pseudowire 109 S-PE: Switching Provider Edge Node of MS-PW 111 T-PE: Terminating Provider Edge Node of MS-PW 113 4. Applicability 115 The procedures described in this draft are intended for the case 116 where PWs are statically configured. Where an LDP control plane 117 exists, this MUST be used for signaling all PW status messages with 118 the exception of those specified in [REDUNDANCY]. For [REDUNDANCY], 119 the 'S-PE' bypass mode described below MAY be used in the presence of 120 an LDP control plane. 122 5. Pseudowire Status Operation 124 5.1. PW OAM Message 126 The PW status TLV as defined in [RFC4447] sec 5.4.2 is transported in 127 a PW OAM message using the PW associated channel (ACH). 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | ACH TLV Header | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Refresh Timer | TLV Length |A| Flags | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 ~ TLVs ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 1: ACH PW OAM Message Packet Header. 143 The first 32 bits are the standard ACH header construct as defined in 144 [RFC5586]. 146 The first nibble (0001b) indicates the ACH instead of PW data. The 147 version and the reserved values are both set to 0 as specified in 148 [RFC4385]. 150 The ACH TLV header is defined in [RFC5586] section 3.2, and contains 151 the length of ACH TLVs. In this application the long word is set to 0 152 as there are no ACH TLVs. 154 The refresh timer is an unsigned integer and specifies refresh time 155 in seconds with a range from 1 to 65535. The value 0 means that the 156 refresh timer is set indefinitely, and the PW OAM message will never 157 be refreshed, and will never timeout. This mode SHOULD NOT be used 158 other then when specified in this document. 160 The TLV length field indicates the length of all PW OAM TLVs only. 162 The A flag bit is used to indicate an acknowledgment of the PW status 163 TLV included. The rest of the flag bits are reserved and they must be 164 set to 0 on transmit, and ignored upon receive. When the A bit is 165 set, the refresh timer value is a requested timer value. PW OAM 166 Message code point = 0xZZ. [ZZ to be assigned by IANA from the PW 167 Associated Channel Type registry.] 168 TLV types for use in this message are allocated by IANA in the LDP 169 registry named: "TLV TYPE NAME SPACE" . 171 5.2. Sending a PW Status Message 173 PW Status messages are indicated by sending in-band PW OAM messages 174 for a particular PW containing the PW Status TLV defined in 175 [RFC4447]. The PW Status TLV format is as follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |Res| PW Status (0x096A) | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Status Code | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: PW Status Message Format. 186 The first 2 bits are reserved, and MUST be set to zero on transmit, 187 and ignored on receive. 189 The PW Status TLV is prepended with an PW OAM message header and sent 190 on the ACH of the PW to which the status update applies. 192 To clear a particular status indication, the PE needs to send a new 193 PW OAM message containing a PW Status TLV with the corresponding bit 194 cleared. 196 The procedures described in [RFC6073] that apply to an S-PE and PW 197 using an LDP control plane also apply when sending PW status using 198 the PE OAM channel. The OPTIONAL procedures using the S-PE TLV 199 described in [RFC6073] can also be applied when sending PW status 200 using the PE OAM channel. 202 The detailed message transmit, and receive procedures are specified 203 in the next section. PW OAM Status Messages MUST NOT be used as a 204 connectivity verification method. 206 5.3. PW OAM status message transmit and receive 208 Unlike the PW status procedures defined in [RFC4447] with this method 209 there is no TCP/IP session, or session management. Therefore unlike 210 in the TCP/IP case, where the message is sent only once, the PW OAM 211 message containing the PW status TLV needs to be transmitted 212 repeatedly to ensure reliable message delivery. 214 The PW OAM message containing a PW status TLV with a new status bit 215 set, will be transmitted twice at an initial interval of one second. 216 Subsequently the PW OAM message will be transmitted with an interval 217 specified by the refresh timer value in the packet. Note that this 218 value MAY be updated in the new PW OAM message packet, in which case 219 the new refresh timer value becomes the new packet transmit interval. 221 The suggested default value for the refresh timer is 30 seconds. 223 When a PW OAM message containing a status TLV is received, a timer is 224 started according to the refresh rate specified in the packet. If 225 another non zero PW status message is not received within 3.5 times 226 the specified timer value, the status condition will timeout in 3.5 227 times the last refresh timer value received, and the default status 228 of zero is assumed on the PW. It is also a good practice to introduce 229 some jitter in the delay between refresh transmissions, as long as 230 the maximum jitter delay is within the prescribed maximum refresh 231 time of 3.5 times the specified timer value for 3 consecutive refresh 232 packets. 234 To clear a particular status fault the PE need only send an updated 235 message with the corresponding bit cleared. If the PW status word is 236 zero, the PW OAM message will be sent with the method described 237 above, however it MUST be acknowledged with a packet with a timer 238 value of zero. This will cause the PE sending the message to stop 239 sending, and continue normal operation. 241 The message containing the clear status TLV is sent according to the 242 same rules defined above. 244 5.3.1. Acknowledge of PW status 246 The PE receiving a PW OAM message containing a PW status message can 247 acknowledge the PW status message by simply building an almost 248 identical reply packet with the A bit set, and transmitting it on the 249 PW ACH back to the source of the PW status message. The timer value 250 set in the reply packet will then be used as the new transmit 251 interval. If the sender PE of a PW status message receives an 252 acknowledge for a particular message where the PW status TLV matches 253 exactly the PW status TLV in the message that is currently being 254 refreshed, the sender PE MUST use the new timer value received. 256 The suggested default value for the refresh timer value in the 257 acknowledge packet is 600 seconds. 259 If the sender PE receives an acknowledge message that does not match 260 the current active PW status message being sent, it simply ignores 261 the acknowledgment packet. 263 If a PE that has a non zero status word for a particular PW, detect 264 by any means that the peer PW has become unreachable, it will follow 265 the standard procedures and consider that PW as having an additional 266 status bit set. This would, normally trigger sending updates again, 267 and canceling the acknowledge refresh timer state. 269 5.3.2. Applicable PW status Bits 271 In some situations it might not be useful or possible to transit a PW 272 status message because the remote PE is not reachable. For example a 273 PE that detects a local PSN TX fault condition, will be unable to 274 transmit a PW OAM message with a PW status TLV reflecting that 275 condition. The general rule is that a PE or S-PE should always 276 attempt to send a PW status message. 278 5.4. MPLS Label Stack 280 With one exception, all PW OAM status messages are are sent to the 281 adjacent PE across the PSN tunnel. in many cases the transmitting PE 282 has no way to determine whether the adjacent PE is a S-PE, or a T-PE. 283 This is a necessary behavior to preserve backward compatibility with 284 PEs that do not understand MS-PWs. In the procedures described in 285 this document there are two possible destinations for the PW OAM 286 status messages: the adjacent PE, or the T-PE. Sending a PW status 287 message directly to the T-PE is a enhanced method that is only 288 applicable using PW OAM status messages sent in the PW ACH. 290 5.4.1. Label stack for a message destined to the next PE 292 A PE that needs to forward a PW OAM status message to the adjacent PE 293 across the PSN tunnel, MUST set the PW label TTL field to 1. 294 Furthermore if the control word is not in use on the particular PW, 295 the PE MUST also place the GAL reserved label [RFC5586], below the PW 296 label also with the TTL field set to 1. 298 5.4.2. Label stack for a message destined to the egress PE 300 This is also known as "S-PE bypass mode" see below. A T-PE that 301 requires sending a PW OAM status message directly to the 302 corresponding T-PE at the other end of the PW MUST set the TTL of the 303 PW label to a value that is sufficient to reach the corresponding T- 304 PE. This value will be greater then one, but will be set according to 305 the local policy on the transmitting T-PE. Furthermore if the control 306 word is not in use on the particular PW, the PE MUST also place the 307 GAL reserved label [RFC5586], below the PW label with the TTL field 308 set to 1. 310 5.5. S-PE bypass mode 312 S-PE bypass mode enables a T-PE to bypass all S-PEs that might be 313 present along the MS-PW and to send a message directly to the remote 314 T-PE. This is used for very fast message transmission in-band with 315 the PW PDUs. This mode is OPTIONAL, and must be supported by both T- 316 PEs to be enabled. 318 Note that this method MUST NOT be used to send messages which are 319 permitted to originate at an S-PE, since otherwise race conditions 320 could occur between messages sent via the control plane by S-PEs, and 321 messages sent via the data plane by T-PEs. 323 Currently the only PW status codes which MAY be sent using the S-PE 324 bypass procedure are: 326 0x00000002 - Local Attachment Circuit (ingress) Receive Fault 327 0x00000004 - Local Attachment Circuit (egress) Transmit Fault 329 Note that since "clear all failures" may be sent by an S-PE it MUST 330 NOT be sent using the S-PE bypass mode. 332 When S-PE bypass mode is enabled, all PW Status TLVs received using 333 this method have priority over PW Status TLVs sent via control 334 protocols such as LDP [RFC4447]. 336 5.5.1. S-PE bypass mode LDP flag bit 338 When a PW Segment along an MS-PW is using the LDP control protocol, a 339 flag bit MUST be set in the interface parameters sub-TLV to indicate 340 that the T-PE is requesting S-PE bypass status message mode. If the 341 S-PE bypass mode LDP flag bit in the generic protocol flags interface 342 parameter does not mach in the FEC advertisement for directions of a 343 specific PW, that PW MUST NOT be enabled. 345 The interface parameter is defined as follow: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Type=0X16 | Length=4 |R R R R R R R R R R R R R R R B| 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Generic Protocol Flags. 355 - TLV Type. 357 Type 0x16 - Generic Protocol Flags. Note: Value 0x16 suggested 358 for assignment pending IANA allocation. 360 - Length 362 TLV length always 4 octets. 364 - Flags 366 Protocol flags, Bit B is set to request the S-PE bypass mode. 367 Bits R are reserved for future use, and must be zero on 368 transmission, and ignored on reception of this TLV. 370 5.5.2. S-PE bypass mode negotiation procedure 372 To be written in the next revision. 374 6. S-PE operation 376 The S-PE will operate according to the procedures defined in 377 [RFC6073]. The following additional procedures apply to the case 378 where a static PW segment is switched to a dynamic PW segment that 379 uses LDP, and the case a static PW segment is switched to another 380 static PW segment. 382 6.1. Static PW to another Static PW 384 The procedures that are described in [RFC6073] section 10 also apply 385 to the case of a static PW switched to another static PW. The LDP 386 header is simply replaced by the PE OAM header, otherwise the packet 387 format will be identical. The information that is necessary to form a 388 SP-PE TLV MUST be configured in the S-PE, or no S-PE TLV will be 389 sent. The Document [RFC6073] defines a IANA registry named 390 "Pseudowire Switching Point PE TLV Type". In order to support the 391 static PW configuration and addressing scheme, a new code point is 392 requested as follows: 394 Type Length Description 395 0x07 24 Static PW/MPLS-TP PW segment ID of last 396 PW segment traversed 398 The format of this TLV is that of the "Static Pseudowire Sub-TLV" 399 defined in [ON DEMAND]. 401 6.2. Dynamic PW to Static PW or vice versa 403 The procedures that are described in [RFC6073] section 10 also apply 404 to this situation. However if the PW label of the LDP controlled PW 405 segment is withdrawn, by the adjacent PE, the S-PE will set the PW 406 status code "0x00000001 - Pseudowire Not Forwarding" to the adjacent 407 PW on the static PW segment. 409 The S-PE will only withdraw its label for the dynamic, LDP 410 controlled, PW segment if the S-PE is un-provisioned. 412 7. Security Considerations 414 The security measures described in [RFC4447] and [RFC6073] are 415 adequate for the proposed mechanism. 417 8. IANA Considerations 419 This document uses a new Associated Channel Type. IANA already 420 maintains a registry of name "Pseudowire Associated Channel Types". A 421 value of 0x0022 is suggested for assignment with TLVs. The 422 description is "PW OAM Message". 424 This document uses a new Pseudowire Switching Point PE TLV Type. IANA 425 already maintains a registry of name "Pseudowire Switching Point PE 426 TLV Type". A value of 0x07 is suggested for assignment. The 427 description is "Static PW/MPLS-TP PW segment ID of last PW segment 428 traversed". 430 This document uses a new interface parameter type. IANA already 431 maintains a registry of name "Pseudowire Interface Parameters Sub-TLV 432 type Registry". A value of 0x16 is suggested for assignment. The 433 description is "Generic Protocol Flags". 435 9. References 437 9.1. Normative References 439 [RFC2119] Bradner. S, "Key words for use in RFCs to 440 Indicate Requirement Levels", RFC 2119, March, 1997. 442 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 443 et al., rfc4447 April 2006. 445 [RFC6073] Martini et.al. "Segmented Pseudowire", 446 RFC 6073, January 2011. 448 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 449 Control Word for Use over an MPLS PSN", S. Bryant, et al., 450 RFC4385, February 2006. 452 [REDUNDANCY] Muley et.al. "Preferential Forwarding Status 453 bit definition", draft-ietf-pwe3-redundancy-bit-03.txt, 454 IETF Work in Progress, May 2010. 456 [ON DEMAND] Bahadur et.al. "MPLS on-demand Connectivity 457 Verification, Route Tracing and Adjacency Verification", 458 draft-ietf-mpls-tp-on-demand-cv-02.txt, IETF Work in Progress, 459 October 2010 461 9.2. Informative References 463 [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed., 464 "MPLS Generic Associated Channel", rfc5586, June 2009 466 10. Author's Addresses 468 Luca Martini 469 Cisco Systems, Inc. 470 9155 East Nichols Avenue, Suite 400 471 Englewood, CO, 80112 472 e-mail: lmartini@cisco.com 474 George Swallow 475 Cisco Systems, Inc. 476 300 Beaver Brook Road 477 Boxborough, Massachusetts 01719 478 United States 479 e-mail: swallow@cisco.com 481 Giles Heron 482 Cisco Systems 483 9-11 New Square 484 Bedfont Lakes 485 Feltham 486 Middlesex 487 TW14 8HA 488 United Kingdom 489 e-mail: giheron@cisco.com 491 Matthew Bocci 492 Alcatel-Lucent 493 Grove House, Waltham Road Rd 494 White Waltham, Berks, UK. SL6 3TN 495 e-mail: matthew.bocci@alcatel-lucent.co.uk 497 Copyright Notice 499 Copyright (c) 2011 IETF Trust and the persons identified as the 500 document authors. All rights reserved. 502 This document is subject to BCP 78 and the IETF Trust's Legal 503 Provisions Relating to IETF Documents 504 (http://trustee.ietf.org/license-info) in effect on the date of 505 publication of this document. Please review these documents 506 carefully, as they describe your rights and restrictions with respect 507 to this document. Code Components extracted from this document must 508 include Simplified BSD License text as described in Section 4.e of 509 the Trust Legal Provisions and are provided without warranty as 510 described in the Simplified BSD License. 512 Expiration Date: September 2011