idnits 2.17.1 draft-muley-dutta-pwe3-redundancy-bit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 28. -- Found old boilerplate from RFC 3978, Section 5.3 on line 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 441. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2007) is 6271 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 (ref. '2') (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 3036 (ref. '3') (Obsoleted by RFC 5036) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Praveen Muley 2 Internet Draft Mustapha Aissaoui 3 Intended status: Standards Track Matthew Bocci 4 Expires: August 2007 Pranjal Kumar Dutta 5 Marc Lasserre 6 Alcatel-Lucent 8 Jonathan Newton 9 Cable & Wireless 11 Olen Stokes 12 Extreme Networks 14 Hamid Ould-Brahim 15 Nortel 17 February 25, 2007 19 Preferential Forwarding Status bit definition 20 draft-muley-dutta-pwe3-redundancy-bit-00.txt 22 Status of this Memo 24 By submitting this Internet-Draft, each author represents that 25 any applicable patent or other IPR claims of which he or she is 26 aware have been or will be disclosed, and any of which he or she 27 becomes aware will be disclosed, in accordance with Section 6 of 28 BCP 79. 30 This document may only be posted in an Internet-Draft. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on August 25, 2007. 50 Abstract 52 This document describes a mechanism for standby status signaling of 53 redundant PWs between its termination points. A set of redundant PWs 54 is configured between PE nodes in SS-PW applications, or between T-PE 55 nodes in MS-PW applications. In order for the PE/T-PE nodes to 56 indicate the preferred PW path to forward to one another, a new 57 status bit is needed to indicate the preferential forwarding status 58 of active or standby for each PW in the redundancy set. This draft 59 specifies a new PW status bit for this purpose. 61 Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC-2119 [1]. 67 Table of Contents 69 1. Introduction...................................................3 70 2. Motivation.....................................................3 71 3. Signaling procedures of PW State Transition....................4 72 3.1. PW Standby notification procedures in Master/Slave mode...5 73 3.1.1. PW State Machine.....................................6 74 3.2. PW Standby notification procedures in Independent mode....8 75 4. Applicability..................................................8 76 5. Security Considerations........................................8 77 6. IANA Considerations............................................9 78 6.1. Status Code for PW Preferential Forwarding Status.........9 79 7. Acknowledgments................................................9 80 8. References.....................................................9 81 8.1. Normative References......................................9 82 8.2. Informative References....................................9 83 Author's Addresses...............................................10 84 Intellectual Property Statement..................................11 85 Disclaimer of Validity...........................................12 86 Acknowledgment...................................................12 88 o 90 1. Introduction 92 In single-segment PW (SS-PW) services such as VPWS and VPLS, 93 protection for the PW is provided by the PSN layer. This may be an 94 RSVP LSP with a FRR backup and/or an end-to-end backup LSP. There are 95 however applications where the backup PW terminates on a different 96 target PE node. In a VPWS service, this is used to provide access AC 97 redundancy to a CE device which is dual-homed to target PE nodes. In 98 a HVPLS service, this is used to provide access PW redundancy to the 99 MTU device which is dual-homed to two PE-r devices. More details are 100 provided in [4]. PSN protection mechanisms cannot protect against 101 failure of the target PE node or the failure of the remote AC. 103 In multi-segment PW (MS-PW) applications, a primary and multiple 104 secondary PWs in standby mode are configured in the network. The 105 paths of these PWs are diverse and are switched at different S-PE 106 nodes. In these applications, PW redundancy is important for the 107 service resilience. 109 This document specifies a new PW status bit to indicate the 110 preferential forwarding status of the PW for the purpose of notifying 111 the remote PE of the active/standby state of each PW in the 112 redundancy set. This status bit is different from the operational 113 status bits already defined in the PWE3 control protocol [2]. 115 2. Motivation 117 Currently the operational status defined in the PWE3 control protocol 118 [2] introduces two states to AC and PW, Operationally UP or DOWN. The 119 scenarios defined in [4] require more states to make forwarding 120 decision of the traffic. This draft defines a new status bit called 121 preferential forwarding status bit and introduces two additional 122 states to PW, Active and Standby, to indicate the preferred PW path 123 to forward traffic to one another. 125 o Active State 127 A PW is considered to be in Active state when the PW labels are 128 exchanged between its two terminating points in control plane and the 129 corresponding data path is established. In this state data traffic 130 can flow over the PW in both directions. A PW by default is always in 131 Active state after it is set UP by signaling. 133 o Standby State 135 A PW is considered to be in Standby state when the PW labels are 136 exchanged between its two terminating points in the control plane but 137 the data traffic is blocked at either or both the ends. In this state 138 the blocked end(s) of the PW SHOULD NOT forward data traffic over the 139 PW but MUST allow PW OAM packets (e.g, VCCV) to be sent and received. 140 How a PW should be blocked only for data traffic is implementation 141 specific and is out of scope of this document. In the context of this 142 document "blocking" a PW means blocking data traffic only and 143 "unblocking" as vice versa unless specified otherwise. 145 The preferential forwarding status of active or standby for each PW 146 in the redundancy set determines the selection of the PW a PE/T-PE 147 forwards traffic to. There are two modes of operation for the PW 148 redundancy: 150 1. Synchronization of PW paths not mandatory (Independent Mode): 152 PW endpoint nodes advertise independently their Active/Standby states 153 and each compares local and remote status and select the PW which is 154 operationally UP and shows both local Active and remote Active in 155 preference to the other combination of states. If such PW is not 156 found, then a PE/T-PE MAY forward over a PW which is Active locally 157 and Standby remotely. No error condition is generated and thus 158 asymmetric PW path forwarding is allowed. 160 2. Synchronization of PW paths mandatory (Master/Slave Mode): 162 A Master/Slave operation is required between the endpoint nodes of 163 the PWs. There is a single PE/T-PE Master node and one or many PE/T- 164 PE Slave nodes. The assignment of Master/Slave roles to the nodes is 165 performed by local configuration. 167 The Master node ignores the Active/Standby status bits received from 168 the Slave nodes. The Slave nodes are required to act on the status 169 bits received from the Master node. When the received status bit 170 transitions from Active to Standby, a Slave node SHOULD block 171 forwarding over the PW. If it fails to block it, it does nothing. 172 When the received status bit transitions from Standby to Active, the 173 Slave node MUST unblock forwarding over the PW. It fails to block it, 174 it generates a status bit of "PW not forwarding" back to the Master. 176 The Master node then unblocks another PW and if successful will reset 177 the status bit to Standby towards the Slave node that advertised "PW 178 not forwarding". 180 3. Signaling procedures of PW State Transition 182 This section describes the extensions proposed and the processing 183 rules for the extensions. It defines a new "PW preferential 184 forwarding" bit in Status Code that is to be used with PW Status TLV 185 proposed in [2]. The PW preferential forwarding bit when set is used 186 to signal Standby state of PW by one terminating point to the other 187 end. An implementation that uses this mechanism MUST negotiate the 188 usage of PW status TLV between its T-LDP peers as per [2]. If PW 189 Status TLV is found to be not supported by either of its endpoint 190 after status negotiation procedures then the mechanism proposed in 191 this document SHOULD NOT be used. 193 3.1. PW Standby notification procedures in Master/Slave mode 195 The central concept of this mechanism is that whenever the Master PW 196 termination point "actively" blocks or unblocks the PW at its end, it 197 explicitly notifies the event to the remote Slave termination point. 198 The slave point carries out the corresponding action on receiving the 199 PW state change notification. Presence of the PW Standby bit in PW 200 Status TLV indicates that the PW at the disposing end is blocked and 201 kept in Standby state, and the PW SHOULD also be blocked at receiving 202 end. Clearance of the PW Standby bit in PW Status TLV indicates that 203 the PW at the disposing end is unblocked and is in Active state, and 204 the receiving end SHOULD make the PW Active if it is blocked earlier. 205 If the receiving end (slave node) is successful in carrying out the 206 required action it SHOULD NOT notify disposing end as its role in 207 this event is passive. If the receiving end fails to block the PW at 208 its end it SHOULD NOT notify about its failure as anyway the PW is 209 blocked at disposing end. If the receiving end fails to unblock the 210 PW it SHOULD notify it as fatal error to the disposing end. The 211 status bit proposed for this notification is the "PW not forwarding". 212 This mode of signaling is necessary to keep the termination points of 213 a PW synchronized in states with respect to each other. 215 The mechanism is RECOMMENDED to be used with PWs 216 signaled in groups with common group-id in PWid FEC Element or 217 Grouping TLV in Generalized PWid FEC Element defined in [2]. When PWs 218 are provisioned with such grouping a termination point sends a single 219 "wildcard" Notification message using a PW FEC TLV with only the 220 group ID set, to denote this change in status for all affected PW 221 connections. This status message contains either the PW FEC TLV with 222 only the Group ID set, or else it contains the PW Generalized FEC TLV 223 with only the PW Grouping ID TLV. As mentioned in [2], the Group ID 224 field of the PWid FEC Element, or the PW Grouping TLV used with the 225 Generalized ID FEC Element, can be used to send status notification 226 for all arbitrary set of PWs. For example, Group-ID in PWiD may be 227 used to send wildcard status notification message for a group of PWs 228 when PWid FEC element is used for PW state signaling. When 229 Generalized PWiD FEC Element defined is used in PW state signaling, 230 PW Grouping TLV may be used for wildcard status notification for a 231 group of PWs. 233 In MS-PW application, the S-PE nodes relay the PW 234 status notification containing both the operational and preferential 235 forwarding status to the T-PE nodes. 237 3.1.1. PW State Machine 239 It is convenient to describe the PW state change behavior in terms of 240 a state machine. The PW state machine is explained in detail in the 241 two defined states and the behavior is presented as a state 242 transition table. The same state machine is seamlessly applicable to 243 PW Groups. 245 PW State Transition State Table 247 STATE EVENT NEW STATE 249 ACTIVE PW blocked actively STANDBY 251 Action: Transmit PW Standby bit set 253 Receive PW Standby bit set STANDBY 255 Action: PW blocked 257 Receive PW Standby bit set ACTIVE 259 but PW blocking failed 261 Action : None 263 Receive PW Standby bit set ACTIVE 264 but PW Standby bit not supported 266 Action: None 268 Receive PW Standby bit clear ACTIVE 270 Action: None. 272 Receive PW Not Forwarding bit set Applicable state 274 Action: Applicable as per [2] as per [2] 276 STANDBY PW unblocked actively ACTIVE 278 Action : Transmit PW Standby 280 bit clear 282 Receive PW Standby bit clear ACTIVE 284 Action: PW unblocked 286 Receive PW Standby bit clear Applicable state 288 but PW unblocking failed as per [2] 290 Action : Transmit PW Not Forwarding 292 bit. 294 Receive PW Not Forwarding bit set Applicable state 296 Action: Applicable procedure as per [2] as per [2] 297 Receive PW Standby bit set STANDBY 299 Action :No action 301 3.2. PW Standby notification procedures in Independent mode 303 In this mode of operation, each endpoint of the PW selects 304 independently which PW to activate based on the specific application. 305 The endpoints advertise the resulting Active/Standby status over all 306 PWs in the redundancy set. 308 Each endpoint compares local and remote status and MUST select the PW 309 which shows local Active and remote Active in preference to any other 310 combination of local and remote forwarding states. If multiple PWs 311 show Active/Active, then the PW to forward traffic to is a local 312 endpoint decision. Thus, asymmetric forwarding over the PW paths is 313 allowed in this mode. 315 If there is no Active/Active PW, then an endpoint MAY forward over a 316 PW which shows other combination of forwarding states. However, the 317 receiving end may discard the received packets. No error messages are 318 sent in this case. 320 In MS-PW application, the S-PE nodes relay the PW status notification 321 containing both the operational and preferential forwarding status to 322 the T-PE nodes. 324 4. Applicability 326 The mechanism defined in this document is OPTIONAL and is applicable 327 to PWE3 applications where standby state signaling of PW or PW group 328 is required. Application of the mechanism for P2MP and MP2MP PW is 329 again outside the scope and is a subject of future study. 331 5. Security Considerations 333 This document uses the LDP extensions that are needed for protecting 334 pseudo-wires. It will have the same security properties as in LDP [3] 335 and the PW control protocol [2]. 337 6. IANA Considerations 339 We have defined the following codes for the pseudo-wire redundancy 340 application. 342 6.1. Status Code for PW Preferential Forwarding Status 344 The PE/T-PE nodes need to indicate to each other the preferential 345 forwarding status of active/inactive of the pseudo-wire. 347 0x00000020 When the bit is set, it represents "PW forwarding 349 standby". 351 When the bit is cleared, it represents "PW forwarding 353 active". 355 7. Acknowledgments 357 The authors would like to thank Vach Kompella, Kendall Harvey, 358 Tiberiu Grigoriu, John Rigby, Prashanth Ishwar, Neil Hart, Kajal 359 Saha, Florin Balus and Philippe Niger for their valuable comments and 360 suggestions. 362 8. References 364 8.1. Normative References 366 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 367 Levels", BCP 14, RFC 2119, March 1997. 369 [2] Martini, L., et al., "Pseudowire Setup and Maintenance using 370 LDP", RFC 4447, April 2006. 372 [3] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 373 Thomas, "LDP Specification", RFC 3036, January 2001 375 8.2. Informative References 377 [4] Praveen, Pranjal et al., "draft-muley-pwe3-redundancy-01.txt" , 378 August 2007. 380 Author's Addresses 382 Praveen Muley 383 Alcatel-Lucent 384 701 E. Middlefiled Road 385 Mountain View, CA, USA 386 Email: Praveen.muley@alcatel-lucent.com 388 Mustapha Aissaoui 389 Alcatel-Lucent 390 600 March Rd 391 Kanata, ON, Canada K2K 2E6 392 Email: mustapha.aissaoui@alcatel-lucent.com 393 Matthew Bocci 394 Alcatel-Lucent 395 Voyager Place, Shoppenhangers Rd 396 Maidenhead, Berks, UK SL6 2PJ 397 Email: matthew.bocci@alcatel-lucent.co.uk 399 Pranjal Kumar Dutta 400 Alcatel-Lucent 401 Email: pdutta@alcatel-lucent.com 403 Marc Lasserre 404 Alcatel-Lucent 405 Email: mlasserre@alcatel-lucent.com 407 Jonathan Newton 408 Cable & Wireless 409 Email: Jonathan.Newton@cwmsg.cwplc.com 411 Olen Stokes 412 Extreme Networks 413 Email: ostokes@extremenetworks.com 415 Hamid Ould-Brahim 416 Nortel 417 Email: hbrahim@nortel.com 419 Intellectual Property Statement 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed to 423 pertain to the implementation or use of the technology described in 424 this document or the extent to which any license under such rights 425 might or might not be available; nor does it represent that it has 426 made any independent effort to identify any such rights. Information 427 on the procedures with respect to rights in RFC documents can be 428 found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use of 433 such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository at 435 http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at 441 ietf-ipr@ietf.org. 443 Disclaimer of Validity 445 This document and the information contained herein are provided on an 446 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 447 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 448 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 449 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 450 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 451 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 Copyright Statement 455 Copyright (C) The IETF Trust (2007). 457 This document is subject to the rights, licenses and restrictions 458 contained in BCP 78, and except as set forth therein, the authors 459 retain all their rights. 461 Acknowledgment 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society.