idnits 2.17.1 draft-asm-mpls-tp-bfd-cc-cv-04.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 (May 11, 2010) is 5092 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) == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Dave Allan, Ed. 2 Internet Draft Ericsson 3 Intended status: Standards Track 4 Expires: November 2010 George Swallow Ed. 5 Cisco Systems, Inc 7 John Drake Ed. 8 Juniper 10 May 11, 2010 12 Proactive Connection Verification, Continuity Check and Remote 13 Defect indication for MPLS Transport Profile 14 draft-asm-mpls-tp-bfd-cc-cv-04 16 Abstract 18 Continuity Check (CC), Proactive Connectivity Verification (CV) and 19 Remote Defect Indication (RDI) functionalities required for are MPLS- 20 TP OAM. 22 Continuity Check monitors the integrity of the continuity of the path 23 for any loss of continuity defect. Connectivity verification monitors 24 the integrity of the routing of the path between sink and source for 25 any connectivity issues. RDI enables an End Point to report, to its 26 associated End Point, a fault or defect condition that it detects on 27 a PW, LSP or Section. 29 This document specifies methods for proactive CV, CC, and RDI for 30 MPLS-TP Label Switched Path (LSP), PWs and Sections using 31 Bidirectional Forwarding Detection (BFD). 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC2119 [1]. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance 42 with the provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet 45 Engineering Task Force (IETF), its areas, and its working 46 groups. Note that other groups may also distribute working 47 documents as Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six 50 months and may be updated, replaced, or obsoleted by other 51 documents at any time. It is inappropriate to use Internet- 52 Drafts as reference material or to cite them other than as "work 53 in progress". 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt. 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html. 61 This Internet-Draft will expire on November 11, 2010. 63 Copyright Notice 65 Copyright (c) 2010 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with 73 respect to this document. 75 Table of Contents 77 1. Introduction..........................................3 78 1.1. Authors.............................................3 79 2. Conventions used in this document........................4 80 2.1. Terminology.........................................4 81 2.2. Issues for discussion.................................4 82 3. MPLS CC, proactive CV and RDI Mechanism using BFD...........5 83 3.1. ACH code points for CC and proactive CV..................5 84 3.2. MPLS BFD CC Message format.............................6 85 3.3. MPLS BFD proactive CV Message format....................6 86 3.4. BFD Session in MPLS-TP terminology......................7 87 3.5. BFD Profile for MPLS-TP...............................7 88 3.5.1. Session initiation..................................8 89 3.5.2. Defect entry criteria...............................8 90 3.5.3. Defect entry consequent action .......................9 91 3.5.4. Defect exit criteria................................9 92 3.5.5. Configuration of MPLS-TP BFD sessions.................10 93 3.5.6. Discriminator values...............................10 94 4. Acknowledgments.......................................10 95 5. IANA Considerations...................................10 96 6. Security Considerations................................11 97 7. References...........................................11 98 7.1. Normative References.................................11 99 7.2. Informative References...............................11 101 1. Introduction 103 In traditional transport networks, circuits are provisioned on two or 104 more switches. Service Providers (SP) need OAM tools to detect mis- 105 connectivity and loss of continuity of transport circuits. Both PWs 106 and MPLS-TP LSPs [6] emulating traditional transport circuits need to 107 provide the same CC and proactive CV capabilities as required in 108 draft-ietf-mpls-tp-oam-requirements[3]. This document describes the 109 use of BFD for CC, proactive CV, and RDI of a PW, LSP or PST between 110 two Maintenance Entity Group End Points (MEPs). 112 As described in [8], Continuity Check (CC) and Proactive Connectivity 113 Verification (CV) functions are used to detect loss of continuity 114 (LOC), and unintended connectivity between two MEPs (e.g. mismerging 115 or misconnection or unexpected MEP). 117 The Remote Defect Indication (RDI) is an indicator that is 118 transmitted by a MEP to communicate to its peer MEP that a signal 119 fail condition exists. RDI is only used for bidirectional connections 120 and is associated with proactive CC & CV packet generation. 122 This document specifies the BFD extension and behavior to satisfy the 123 CC, proactive CV monitoring and the RDI functional requirements for 124 bi-directional paths. Procedures for uni-directional paths are for 125 further study. 127 The mechanisms specified in this document are restricted to BFD 128 asynchronous mode. 130 1.1. Authors 132 David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami 133 Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. 135 2. Conventions used in this document 137 2.1. Terminology 139 ACH: Associated Channel Header 141 BFD: Bidirectional Forwarding Detection 143 CV: Connection Verification 145 GAL: Generalized Alert Label 147 LSR: Label Switching Router 149 MEG: Maintenance Entity Group 151 MEP: Maintenance Entity Group End Point 153 MIP: Maintenance Entity Group Intermediate Point 155 MPLS-OAM: MPLS Operations, Administration and Maintenance 157 MPLS-TP: MPLS Transport Profile 159 MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path 160 representing a circuit 162 MS-PW: Multi-Segment PseudoWire 164 NMS: Network Management System 166 PW: Pseudo Wire 168 RDI: Remote Defect Indication. 170 TTL: Time To Live 172 TLV: Type Length Value 174 2.2. Issues for discussion 176 1) Requirement for additional BFD diagnostic codes 178 1. When periodicity of CV cannot be supported 180 2. For mis-connectivity defect 182 2) Do we continue to separate CC and CV as separate functions, or 183 collapse them into a single CC+CV behavior given CV is a superset 184 of CC? 186 3) Is receipt of an unexpected discriminator really a problem? 188 3. MPLS CC, proactive CV and RDI Mechanism using BFD 190 This document proposes distinct encapsulations and code points for 191 BFD depending on whether the mode of operation is CC or CV: 193 o CC mode: defines a new code point in the Associated Channel Header 194 (ACH) described in [2].In this mode Continuity Check and RDI 195 functionalities are supported. 197 o CV mode: defines a new code point in the Associated Channel Header 198 (ACH) described in [2]. Under MPLS label stack, the ACH with "MPLS 199 Proactive CV" code point indicates that the message is an MPLS BFD 200 proactive CV and CC message. 202 o RDI: is communicated via the BFD state field in BFD CC and CV 203 messages. It is not a distinct PDU. 205 3.1. ACH code points for CC and proactive CV 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 |0 0 0 1|Version| Flags |0xHH BFD CC/CV Code Point | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 1: ACH Indication of MPLS-TP Connection Verification 215 The first nibble (0001b) indicates the ACH. 217 The version and the flags are set to 0 as specified in [2]. 219 The code point is either 221 - BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW 222 Associated Channel Type registry.] or, 224 - BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from 225 the PW Associated Channel Type registry.] 227 Both CC and CV modes apply to PWs, MPLS LSPs (including tandem 228 connection monitoring), and Sections. 230 It's possible to run BFD in CC mode on some transport paths and BFD 231 in CV mode on other transport paths. For a given Maintenance Entity 232 Group (MEG) only one mode can be used. A MEP that is configured to 233 support CC mode and receives CV BFD packets, or vice versa, MUST 234 consider them as an unexpected packet, i.e. detect a mis-connectivity 235 defect. 237 3.2. MPLS BFD CC Message format 239 The format of an MPLS CC Message format is shown below. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |0 0 0 1|Version| Flags | 0xHH BFD CC Code point | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 ~ BFD Control Packet ~ 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 2: MPLS CC Message 252 3.3. MPLS BFD proactive CV Message format 254 The format of an MPLS CV Message format is shown below, ACH TLVs [5] 255 MUST precede the BFD control packet. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |0 0 0 1|Version| Flags | 0xHH BFD CV Code Point | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | ACH TLV Header | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 ~ Unique MEP-ID of source of the BFD packet ~ 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 ~ BFD Control Packet ~ 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 3: MPLS CV Message 275 As shown in Figure 3, BFD Control packet as defined in [4] is 276 transmitted as MPLS labeled packets along with ACH, ACH TLV Header 277 defined in Section 3 of RFC 5586 and one ACH TLV object carrying the 278 unique MEP Identifier of the source of the BFD packet defined in [7] 280 When GAL label is used, the TTL field of the GAL MUST be set to at 281 least 1, and the GAL will be the end of stack label (S=1). 283 3.4. BFD Session in MPLS-TP terminology 285 A BFD session corresponds to a CC or a proactive CV OAM instance in 286 MPLS-TP terminology. 288 A BFD session is enabled when the CC or proactive CV functionality is 289 enabled on a configured Maintenance Entity (ME) or in the case of an 290 associated bi-directional path, pair of Maintenance Entities. 292 On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as 293 detailed in [4]. 295 When on a ME the CC or proactive CV functionality is disabled, the 296 BFD session transitions to the ADMIN DOWN State and the BFD session 297 ends. 299 A new BFD session is initiated when the operator enables or re- 300 enables the CC or CV functionality on the same ME. 302 3.5. BFD Profile for MPLS-TP 304 BFD MUST operate in asynchronous mode. In this mode, the BFD Control 305 packets are periodically sent at configurable time rate. This rate is 306 typically a fixed value for the lifetime of the session. In the rare 307 circumstance where an operator has a reason to change session 308 parameters, poll/final discipline is used. 310 The transport profile is designed to operate independent of the 311 control plane; hence the C bit SHOULD be set. 313 This document specifies bi-directional BFD for p2p transport paths, 314 hence the M bit MUST be clear. 316 There are two modes of operation for bi-directional paths. One in 317 which both directions of the path fate share and one constructed from 318 BFD sessions in such a way that the two directions operate 319 independently. A single bi-directional BFD session is used for fate 320 sharing operation. Two independent BFD sessions are used for 321 independent operation. 323 Fate sharing operation is as described in [4]. Independent operation 324 requires clarification of two aspects of [4]. Independent operation 325 is characterized by the setting of MinRxInterval to zero by the MEP 326 that is typically the session originator, and there will be a session 327 originator at either end of the bi-directional path. 329 The base spec is unclear on aspects of how a session with a BFD 330 source set to zero interval behaves. One interpretation is that no 331 periodic messages originate with that source, it will only originate 332 messages on a state change. 334 The first clarification is that when a state change occurs a zero 335 interval source send BFD control messages with a one second period 336 until such time that the state change is confirmed by the session 337 peer. At this point the zero interval source can resume quiescent 338 behavior. This adds robustness to all state transitions in the 339 RxInterval=0 case. 341 The second is that the originating MEP (the one with a non-zero 342 TxInterval) will ignore a DOWN state received from a zero interval 343 peer. This means that the zero interval peer will continue to send 344 DOWN state messages as the state change is never confirmed. This adds 345 robustness to the exchange of RDI indication on a uni-directional 346 failure (for both session types DOWN with a diagnostic of control 347 detection period expired offering RDI functionality). 349 The normal usage is that 1:1 protected paths must use fate sharing, 350 and independent operation applies to 1+1 protected paths. 352 3.5.1. Session initiation 354 In all scenarios a BFD session starts with both ends in the DOWN 355 state. DOWN state messages exchanged include the desired Tx and Rx 356 rates for the session. If a node cannot support the Min Tx rate 357 desired by a peer MEP it does not transition from down to the INIT 358 state and sends a diagnostic code (TBD) indicating that the requested 359 Tx rate cannot be supported. 361 Otherwise once a transition from DOWN to INIT has occurred, the 362 session progresses as per [4]. 364 3.5.2. Defect entry criteria 366 There are further defect criteria beyond that defined in [4] to 367 consider given the possibility of mis-connectivity and mis- 368 configuration defects. The result is the criteria for a path 369 direction to transition from the defect free state to a defect state 370 is a superset of that in the BFD base specification [4]. 372 The following conditions case a MEP to enter the defect state: 373 1. BFD session times out (Loss of Continuity defect), 374 2. BFD control packets are received with an unexpected 375 encapsulation (Mis-connectivity defect), these include 376 - a PW receiving a packet with a GAL 377 - an LSP receiving an IP header instead of a GAL 378 (note there are other possibilities but these can also alias 379 3. Receipt of an unexpected globally unique Source MEP identifier 380 (Mis-connectivity defect), 381 4. Receipt of an unexpected session discriminator (Mis-connectivity 382 defect) 383 5. Receipt of an unexpected M bit (Session Mis-configuration 384 defect) 385 The effective defect hierarchy (order of checking) is 387 1. Receiving nothing 389 2. Receiving from an incorrect source (determined by whatever 390 means) 392 3. Receiving from a correct source (as near as can be determined), 393 but with incorrect session information) 395 4. Receiving control packets in all discernable ways correct. 397 3.5.3. Defect entry consequent action 399 Upon defect entry a sink MEP will assert signal fail into any client 400 (sub-)layers. It will also communicate session DOWN to its session 401 peer. 403 The blocking of traffic as consequent action MUST be driven only by a 404 defect's consequent action as specified in draft-ietf-mpls-tp-oam- 405 framework Error! Reference source not found. section 5.1.1.2. 406 When the defect is mis-braching, the transport path termination will 407 silently discard all non-oam traffic received. 409 3.5.4. Defect exit criteria 411 Exit from a Loss of continuity defect 413 For a fate sharing session exit from a loss of connectivity defect is 414 as described in [4]. 416 For an independent session, exit from a loss of connectivity defect 417 occurs upon receipt of a well formed control packet from the peer 418 MEP. 420 Exit from a session mis-configuration defect 422 [editors: for a future version of the document] 424 Exit from a mis-connectivity defect 426 The exit criteria for a mis-connectivity defect is determined by the 427 maximum of the set of min Rx session time times the multiplier that 428 have been received. A session can transition from DOWN to UP 429 (independent mode) or DOWN to INIT (fate sharing mode) when both 430 correctly formed control packets are being exchanged, and no mis- 431 connected control packets have been received in the specified 432 interval. 434 3.5.5. Configuration of MPLS-TP BFD sessions 436 [Editors note, for a future revision of the document] 438 3.5.6. Discriminator values 440 MPLS labels at peer MEPs are used to provide context for the received 441 BFD packets. 443 In the BFD control packet the discriminator values have either local 444 or no significance. 446 My Discriminator field MUST be set to a nonzero value (it can be a 447 fixed value), the transmitted your discriminator value MUST reflect 448 back the received value of My discriminator field or be set to 0 if 449 that value is not known. 451 4. Acknowledgments 453 To be added in a later version of this document 455 5. IANA Considerations 457 To be added in a later version of this document 459 6. Security Considerations 461 The security considerations for the authentication TLV need further 462 study. 464 Base BFD foresees an optional authentication section (see [4] 465 section 6.7); that can be extended also to the tool proposed in 466 this document. 468 Authentication methods that require checksum calculation on the 469 outgoing packet must extend the checksum also on the ME 470 Identifier Section. This is possible but seems uncorrelated with 471 the solution proposed in this document: it could be better to 472 use the simple password authentication method. 474 7. References 476 7.1. Normative References 478 [1] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC 482 5586 , June 2009 484 [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for 485 OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam- 486 requirements-06 (work in progress), March 2010 488 [4] Katz, D. and D. Ward, "Bidirectional Forwarding 489 Detection", draft-ietf-bfd-base-11 (work in progress), 490 February 2009 492 [5] Boutros, S. et al., "Definition of ACH TLV Structure", 493 draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March 494 2010 496 7.2. Informative References 498 [6] Bocci, M., et al., "A Framework for MPLS in Transport 499 Networks", draft-ietf-mpls-tp-framework-12, (work in 500 progress), May 2010 502 [7] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- 503 swallow-mpls-tp-identifiers-02 (work in progress), March 504 2010 506 [8] Allan, D., Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM 507 Framework", draft-ietf-mpls-tp-oam-framework-06 (work in 508 progress), April 2010 510 Authors' Addresses 512 Dave Allan 513 Ericsson 514 Email: david.i.allan@ericsson.com 516 John Drake 517 Juniper 518 Email: jdrake@juniper.net 520 George Swallow 521 Cisco Systems, Inc. 522 Email: swallow@cisco.com 524 Annamaria Fulignoli 525 Ericsson 526 Email: annamaria.fulignoli@ericsson.com 528 Sami Boutros 529 Cisco Systems, Inc. 530 Email: sboutros@cisco.com 532 Martin Vigoureux 533 Alcatel-Lucent 534 Email: martin.vigoureux@alcatel-lucent.com 536 Siva Sivabalan 537 Cisco Systems, Inc. 538 Email: msiva@cisco.com 540 David Ward 541 Juniper 542 Email: dward@juniper.net