idnits 2.17.1 draft-martini-pwe3-static-pw-status-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (October 24, 2009) is 5298 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 (-18) exists of draft-ietf-pwe3-segmented-pw-13 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-redundancy-bit-01 Summary: 2 errors (**), 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 Cisco 5 Expires: April 24, 2010 6 Matthew Bocci 7 Alcatel-Lucent 9 October 24, 2009 11 Pseudowire Status for Static Pseudowires 13 draft-martini-pwe3-static-pw-status-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 24, 2010 38 Abstract 40 This document specifies a mechanism to signal Pseudowire (PW) status 41 messages using an PW associated channel (ACh). Such a mechanism is 42 suitable for use where no PW dynamic control plane exits, known as 43 static PWs, or where a Terminating Provider Edge (T-PE) needs to send 44 a PW status message directly to a far end T-PE. The mechanism allows 45 PW OAM message mapping and PW redundancy to operate on static PWs. 47 Table of Contents 49 1 Specification of Requirements ........................ 2 50 2 Introduction ......................................... 2 51 3 Terminology .......................................... 3 52 4 Applicability ........................................ 3 53 5 Pseudowire Status Operation .......................... 3 54 5.1 PW OAM Message ....................................... 3 55 5.2 Sending a PW Status Message .......................... 5 56 5.3 PW OAM status message transmit and receive ........... 5 57 5.3.1 Acknowledge of PW status ............................. 6 58 5.3.2 Applicable PW status Bits ............................ 7 59 5.4 MPLS Label Stack ..................................... 7 60 5.4.1 Label stack for a message destined to the next PE .... 7 61 5.4.2 Label stack for a message destined to the egress PE .. 7 62 6 S-PE operation ....................................... 8 63 6.1 Static PW to another Static PW ....................... 8 64 6.2 Dynamic PW to Static PW or vice verso ................ 8 65 7 Security Considerations .............................. 9 66 8 IANA Considerations .................................. 9 67 9 References ........................................... 9 68 9.1 Normative References ................................. 9 69 9.2 Informative References ............................... 10 70 10 Author's Addresses ................................... 10 72 1. Specification of Requirements 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 The default control plane for Pseudowire (PW) technology, as defined 81 in [RFC4447], is based on LDP. However that document also describes a 82 static provisioning mode without control plane. When a static PW is 83 used , there is no method to transmit the status of the PW, or 84 attachment circuit (AC) between the two PEs at each end of the PW. 85 This document defines a method to transport the PW status codes 86 defined in [RFC4447], sec 5.4.2, and [REDUNDANCY] in-band with the PW 87 data using a generic associated channel [RFC5586]. 89 3. Terminology 91 FEC: Forwarding Equivalence Class 93 LDP: Label Distribution Protocol 95 LSP: Label Switching Path 97 MS-PW: Multi-Segment Pseudowire 99 PE: Provider Edge 101 PW: Pseudowire 103 SS-PW: Single-Segment Pseudowire 105 S-PE: Switching Provider Edge Node of MS-PW 107 T-PE: Terminating Provider Edge Node of MS-PW 109 4. Applicability 111 The procedures described in this draft are intended for the case 112 where PWs are statically configured. Where an LDP control plane 113 exists, this MUST be used for signaling all PW status messages with 114 the exception of those specified in [REDUNDANCY]. For [REDUNDANCY], 115 the 'S-PE' bypass mode described below MAY be used in the presence of 116 an LDP control plane. 118 5. Pseudowire Status Operation 120 5.1. PW OAM Message 122 The PW status TLV as defined in [RFC4447] sec 5.4.2 is transported in 123 a PW OAM message using the PW associated channel (ACH). 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |0 0 0 1|Version| Reserved | 0xZZ PW OAM Message | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | ACH TLV Header | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Refresh Timer | TLV Length |A| Flags | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 ~ TLVs ~ 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 1: ACH PW OAM Message Packet Header. 140 The first nibble (0001b) indicates the ACH instead of PW data. The 141 version and the reserved values are both set to 0 as specified in 142 [RFC4385]. 144 The ACH TLV header is defined in [RFC5586] section 3.2, and contains 145 the length of ACH TLVs. In this application the long word is set to 0 146 as there are no ACH TLVs. 148 The refresh timer is an unsigned integer and specifies refresh time 149 in seconds with a range from 1 to 65535. The value 0 means that the 150 refresh timer is set indefinitely, and the PW OAM message will never 151 be refreshed, and will never timeout. This mode SHOULD NOT be used 152 other then when specified in this document. 154 The TLV length field indicates the length of all PW OAM TLVs only. 156 The A flag bit is used to indicate an acknowledgment of the PW status 157 TLV included. The rest of the flag bits are reserved and they must be 158 set to 0 on transmit, and ignored upon receive. When the A bit is set 159 , the refresh timer value is a requested timer value. PW OAM Message 160 code point = 0xZZ. [ZZ to be assigned by IANA from the PW Associated 161 Channel Type registry.] 163 TLV types for use in this message are allocated by IANA in the LDP 164 registry named: "TLV TYPE NAME SPACE" . 166 5.2. Sending a PW Status Message 168 PW Status messages are indicated by sending in-band PW OAM messages 169 for a particular PW containing the PW status TLV defined in 170 [RFC4447]. The PW TLV format is as follows: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |Res| PW Status (0x096A) | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Status Code | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 2: PW Status Message Format. 181 The first 2 bits are reserved , and MUST be set to zero on transmit , 182 and ignored on receive. 184 The PW status TLV is prepended with an PW OAM message header and sent 185 on the ACH of the PW to which the status update applies. 187 To clear a particular status indication, the PE needs to send a new 188 PW OAM message containing a PW Status TLV with the corresponding bit 189 cleared. 191 The procedures described in [SEGMENTED] that apply to an S-PE and PW 192 using an LDP control plane also apply when sending PW status using 193 the PE OAM channel. The OPTIONAL optional procedures using the S-PE 194 TLV described in [SEGMENTED] can also be applied when sending PW 195 status using the PE OAM channel. 197 The detailed message transmit, and receive procedures are specified 198 in the next section. 200 5.3. PW OAM status message transmit and receive 202 Unlike the PW status procedures defined in [RFC4447] with this method 203 there is no TCP/IP session, or session management. Therefore he PW 204 OAM message containing the PW status TLV needs to be transmitted 205 repeatedly to ensure reliable message delivery. 207 The PW OAM message containing a PW status TLV with a new status bit 208 set, will be transmitted twice at an initial interval of one second. 209 Subsequently the PW OAM message will be transmitted with an interval 210 specified by refresh timer value in the packet. Note that this value 211 MAY be updated in the new PW OAM message packet, in which case the 212 new refresh timer value becomes the new packet transmit interval. 214 The suggested dafult value for the refresh timer is 30 seconds. 216 When a PW OAM message containing a status TLV is received, a timer is 217 started according to the refresh rate specified in the packet. If 218 another non zero PW status message is not received within 3.5 times 219 specified timer value, the status condition will timeout in 3.5 times 220 the last refresh timer value received, and the default status of zero 221 is assumed on the PW. 223 To clear a particular status fault the PE need only send an updated 224 message with the corresponding bit cleared. If the PW status word is 225 zero, the PW OAM message will be sent with the method described above 226 , however it MUST be acknowledged with a packet with a timer value of 227 zero. This will cause the PE sending the message to stop sending, and 228 continue normal operation. 230 5.3.1. Acknowledge of PW status 232 The PE receiving a PW OAM message containing a PW status message can 233 acknowledge the PW status message by simply building an almost 234 identical reply packet with the A bit set, and transmitting it on the 235 PW ACH back to the source of the PW status message. The timer value 236 set in the reply packet will then be used as the new transmit 237 interval. If the sender PE of a PW status message receives an 238 acknowledge for a particular message where the PW status TLV matches 239 exactly the PW status TLV in the message that is currently being 240 refreshed, the sender PE MUST use the new timer value received. 242 The suggested default value for the refresh timer value in the 243 acknowledge packet is 600 seconds. 245 If the sender PE receives an acknowledge message that does not match 246 the current active PW status message being sent, it simply ignores 247 the acknowledgment packet. 249 If a PE that has a non zero status word for a particular PW, detect 250 by any means that the peer PW has become unreachable, it will follow 251 the standard procedures and consider that PW as having an additional 252 status bit set. This would, normally trigger sending updates again, 253 and canceling the acknowledge refresh timer state. 255 5.3.2. Applicable PW status Bits 257 In some situations it might not be useful or possible to transit a PW 258 status message because the remote PE is not reachable. For example a 259 PE that detects a local PSN TX fault condition , will be unable to 260 transmit a PW OAM message with a PW status TLV reflecting that 261 condition. The general rule is that a PE or S-PE should always 262 attempt to send a PW status message. 264 5.4. MPLS Label Stack 266 With one exception , all PW OAM status messages are are sent to the 267 adjacent PE across the PSN tunnel. in many cases the transmitting PE 268 has no way to determine whether the adjacent PE is a S-PE , or a T- 269 PE. This is a necessary behavior to preserve backward compatibility 270 with PEs that do not understand MS-PWs. In the procedures described 271 in this document there are two possible destinations for the PW OAM 272 status messages: the adjacent PE, or the T-PE. Sending a PW status 273 message directly to the T-PE is a enhanced method that is only 274 applicable using PW OAM status messages sent in the PW ACH. 276 5.4.1. Label stack for a message destined to the next PE 278 A PE that needs to forward a PW OAM status message to the adjacent PE 279 across the PSN tunnel, MUST set the PW label TTL field to 1. 280 Furthermore if the control word is not in use on the particular PW , 281 the PE MUST also place the GAL reserved label [RFC5586], below the PW 282 label also with the TTL field set to 1. 284 5.4.2. Label stack for a message destined to the egress PE 286 This is known as 'S-PE bypass mode'. A T-PE that requires sending a 287 PW OAM status message directly to the corresponding T-PE at the other 288 end of the PW MUST set the TTL of the PW label to a value that is 289 sufficient to reach the corresponding T-PE. This value will be 290 greater then one, but will be set according to the local policy on 291 the transmitting T-PE. Furthermore if the control word is not in use 292 on the particular PW , the PE MUST also place the GAL reserved label 293 [RFC5586], below the PW label with the TTL field set to 1. 295 It should be noted that this S-PE bypass procedure MUST NOT be used 296 for the following PW status codes: 297 0x00000001 - Pseudowire Not Forwarding 298 0x00000008 - Local PSN-facing PW (ingress) Receive Fault 299 0x00000010 - Local PSN-facing PW (egress) Transmit Fault 300 When a PW status message is sent using this method, the corresponding 301 PW status message to clear the fault MUST also be sent using this 302 method. 304 Editor's note: The method described above does not funtion properly. 305 Therefore it remains here as a point of further study only. 307 6. S-PE operation 309 The S-PE will operate according to the procedures defined in 310 [SEGMENTED]. The following additional procedures apply to the case 311 where a static PW segment is switched to a dynamic PW segment that 312 uses LDP, and the case a static PW segment is switched to another 313 static PW segment. 315 6.1. Static PW to another Static PW 317 The procedures that are described in [SEGMENTED] section 10 also 318 apply to the case of a static PW switched to another static PW. The 319 LDP header is simply replaced by the PE OAM header, otherwise the 320 packet format will be identical. The information that is necessary to 321 form a SP-PE TLV MUST be configured in the S-PE, or no S-PE TLV will 322 be sent. The Document [SEGMENTED] defines a IANA registry named 323 "Pseudowire Switching Point PE TLV Type". In order to support the 324 static PW configuration and adressing scheme, a new code point is 325 requested as follows: 326 Type Length Description 328 0x07 x Static PW/mpls-tp PW segment ID of last 329 PW segment traversed 331 6.2. Dynamic PW to Static PW or vice verso 333 The procedures that are described in [SEGMENTED] section 10 also 334 apply to this situation. However if the PW label of the LDP 335 controlled PW segment is withdrawn, by the adjacent PE, the S-PE will 336 set the PW status code "0x00000001 - Pseudowire Not Forwarding" to 337 the adjacent PW on the static PW segment. 339 The S-PE will only withdraw its label for the dynamic, ldp 340 controlled, PW segment if the S-PE is un-provisioned. 342 7. Security Considerations 344 The security measures described in [RFC4447] and [SEGMENTED] are 345 adequate for the proposed mechanism. 347 8. IANA Considerations 349 This document uses a new Associated Channel Type. IANA already 350 maintains a registry of name "Pseudowire Associated Channel Types". A 351 value of 0x0022 is suggested for assignment with TLVs. The 352 description is "PW OAM Message". 354 This document uses a new Pseudowire Switching Point PE TLV Type. IANA 355 already maintains a registry of name "Pseudowire Switching Point PE 356 TLV Type". A value of 0x07 is suggested for assignment. The 357 description is "Static PW/mpls-tp PW segment ID of last PW segment 358 traversed". 360 9. References 362 9.1. Normative References 364 [RFC2119] Bradner. S, "Key words for use in RFCs to 365 Indicate Requirement Levels", RFC 2119, March, 1997. 367 [RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L., 368 et al., rfc4447 April 2006. 370 [SEGMENTED] Martini et.al. "Segmented Pseudo Wire", 371 draft-ietf-pwe3-segmented-pw-13.txt, IETF Work in Progress, 372 August 2009 374 [RFC4385] " Pseudowire Emulation Edge-to-Edge (PWE3) 375 Control Word for Use over an MPLS PSN", S. Bryant, et al., 376 RFC4385, February 2006. 378 [REDUNDANCY] Muley et.al. "Preferential Forwarding Status 379 bit definition", draft-ietf-pwe3-redundancy-bit-01.txt, 380 IETF Work in Progress, September 2008 382 9.2. Informative References 384 [RFC5586] M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed., 385 "MPLS Generic Associated Channel", rfc5586, June 2009 387 10. Author's Addresses 389 Luca Martini 390 Cisco Systems, Inc. 391 9155 East Nichols Avenue, Suite 400 392 Englewood, CO, 80112 393 e-mail: lmartini@cisco.com 395 George Swallow 396 Cisco Systems, Inc. 397 300 Beaver Brook Road 398 Boxborough, Massachusetts 01719 399 United States 400 e-mail: swallow@cisco.com 402 Matthew Bocci 403 Alcatel-Lucent 404 Grove House, Waltham Road Rd 405 White Waltham, Berks, UK. SL6 3TN 406 e-mail: matthew.bocci@alcatel-lucent.co.uk 408 Full Copyright Statement 410 Copyright (c) 2009 IETF Trust and the persons identified as the 411 document authors. All rights reserved. 413 This document is subject to BCP 78 and the IETF Trust's Legal 414 Provisions Relating to IETF Documents in effect on the date of 415 publication of this document (http://trustee.ietf.org/license-info). 416 Please review these documents carefully, as they describe your rights 417 and restrictions with respect to this document. 419 Expiration Date: April 2010