idnits 2.17.1 draft-ietf-mpls-tp-bfd-cc-cv-00.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 27, 2010) is 5055 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 27, 2010 12 Proactive Connection Verification, Continuity Check and Remote 13 Defect indication for MPLS Transport Profile 14 draft-ietf-mpls-tp-bfd-cc-cv-00 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 28, 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. Code Components extracted from this 74 document must include Simplified BSD License text as described 75 in Section 4.e of the Trust Legal Provisions and are provided 76 without warranty as described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction...................................................3 81 1.1. Authors......................................................3 82 2. Conventions used in this document..............................4 83 2.1. Terminology..................................................4 84 2.2. Issues for discussion........................................4 85 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 86 3.1. ACH code points for CC and proactive CV......................5 87 3.2. MPLS BFD CC Message format...................................6 88 3.3. MPLS BFD proactive CV Message format.........................6 89 3.4. BFD Session in MPLS-TP terminology...........................7 90 3.5. BFD Profile for MPLS-TP......................................7 91 3.5.1. Session initiation.........................................8 92 3.5.2. Defect entry criteria......................................8 93 3.5.3. Defect entry consequent action.............................9 94 3.5.4. Defect exit criteria.......................................9 95 3.5.5. Configuration of MPLS-TP BFD sessions.....................10 96 3.5.6. Discriminator values......................................10 97 4. Acknowledgments...............................................10 98 5. IANA Considerations...........................................10 99 6. Security Considerations.......................................11 100 7. References....................................................11 101 7.1. Normative References........................................11 102 7.2. Informative References......................................11 104 1. Introduction 106 In traditional transport networks, circuits are provisioned on two or 107 more switches. Service Providers (SP) need OAM tools to detect mis- 108 connectivity and loss of continuity of transport circuits. Both PWs 109 and MPLS-TP LSPs [6] emulating traditional transport circuits need to 110 provide the same CC and proactive CV capabilities as required in 111 draft-ietf-mpls-tp-oam-requirements[3]. This document describes the 112 use of BFD for CC, proactive CV, and RDI of a PW, LSP or PST between 113 two Maintenance Entity Group End Points (MEPs). 115 As described in [8], Continuity Check (CC) and Proactive Connectivity 116 Verification (CV) functions are used to detect loss of continuity 117 (LOC), and unintended connectivity between two MEPs (e.g. mismerging 118 or misconnection or unexpected MEP). 120 The Remote Defect Indication (RDI) is an indicator that is 121 transmitted by a MEP to communicate to its peer MEP that a signal 122 fail condition exists. RDI is only used for bidirectional connections 123 and is associated with proactive CC & CV packet generation. 125 This document specifies the BFD extension and behavior to satisfy the 126 CC, proactive CV monitoring and the RDI functional requirements for 127 bi-directional paths. Procedures for uni-directional paths are for 128 further study. 130 The mechanisms specified in this document are restricted to BFD 131 asynchronous mode. 133 1.1. Authors 135 David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami 136 Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. 138 2. Conventions used in this document 140 2.1. Terminology 142 ACH: Associated Channel Header 144 BFD: Bidirectional Forwarding Detection 146 CV: Connection Verification 148 GAL: Generalized Alert Label 150 LSR: Label Switching Router 152 MEG: Maintenance Entity Group 154 MEP: Maintenance Entity Group End Point 156 MIP: Maintenance Entity Group Intermediate Point 158 MPLS-OAM: MPLS Operations, Administration and Maintenance 160 MPLS-TP: MPLS Transport Profile 162 MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path 163 representing a circuit 165 MS-PW: Multi-Segment PseudoWire 167 NMS: Network Management System 169 PW: Pseudo Wire 171 RDI: Remote Defect Indication. 173 TTL: Time To Live 175 TLV: Type Length Value 177 2.2. Issues for discussion 179 1) Requirement for additional BFD diagnostic codes 181 1. When periodicity of CV cannot be supported 183 2. For mis-connectivity defect 185 2) Do we continue to separate CC and CV as separate functions, or 186 collapse them into a single CC+CV behavior given CV is a superset 187 of CC? 189 3) Is receipt of an unexpected discriminator really a problem? 191 3. MPLS CC, proactive CV and RDI Mechanism using BFD 193 This document proposes distinct encapsulations and code points for 194 BFD depending on whether the mode of operation is CC or CV: 196 o CC mode: defines a new code point in the Associated Channel Header 197 (ACH) described in [2].In this mode Continuity Check and RDI 198 functionalities are supported. 200 o CV mode: defines a new code point in the Associated Channel Header 201 (ACH) described in [2]. Under MPLS label stack, the ACH with "MPLS 202 Proactive CV" code point indicates that the message is an MPLS BFD 203 proactive CV and CC message. 205 o RDI: is communicated via the BFD state field in BFD CC and CV 206 messages. It is not a distinct PDU. 208 3.1. ACH code points for CC and proactive CV 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |0 0 0 1|Version| Flags |0xHH BFD CC/CV Code Point | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 1: ACH Indication of MPLS-TP Connection Verification 218 The first nibble (0001b) indicates the ACH. 220 The version and the flags are set to 0 as specified in [2]. 222 The code point is either 224 - BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW 225 Associated Channel Type registry.] or, 227 - BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from 228 the PW Associated Channel Type registry.] 230 Both CC and CV modes apply to PWs, MPLS LSPs (including tandem 231 connection monitoring), and Sections. 233 It's possible to run BFD in CC mode on some transport paths and BFD 234 in CV mode on other transport paths. For a given Maintenance Entity 235 Group (MEG) only one mode can be used. A MEP that is configured to 236 support CC mode and receives CV BFD packets, or vice versa, MUST 237 consider them as an unexpected packet, i.e. detect a mis-connectivity 238 defect. 240 3.2. MPLS BFD CC Message format 242 The format of an MPLS CC Message format is shown below. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |0 0 0 1|Version| Flags | 0xHH BFD CC Code point | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ BFD Control Packet ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 2: MPLS CC Message 255 3.3. MPLS BFD proactive CV Message format 257 The format of an MPLS CV Message format is shown below, ACH TLVs [5] 258 MUST precede the BFD control packet. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |0 0 0 1|Version| Flags | 0xHH BFD CV Code Point | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | ACH TLV Header | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 ~ Unique MEP-ID of source of the BFD packet ~ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 ~ BFD Control Packet ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 3: MPLS CV Message 278 As shown in Figure 3, BFD Control packet as defined in [4] is 279 transmitted as MPLS labeled packets along with ACH, ACH TLV Header 280 defined in Section 3 of RFC 5586 and one ACH TLV object carrying the 281 unique MEP Identifier of the source of the BFD packet defined in [7] 283 When GAL label is used, the TTL field of the GAL MUST be set to at 284 least 1, and the GAL will be the end of stack label (S=1). 286 3.4. BFD Session in MPLS-TP terminology 288 A BFD session corresponds to a CC or a proactive CV OAM instance in 289 MPLS-TP terminology. 291 A BFD session is enabled when the CC or proactive CV functionality is 292 enabled on a configured Maintenance Entity (ME) or in the case of an 293 associated bi-directional path, pair of Maintenance Entities. 295 On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as 296 detailed in [4]. 298 When on a ME the CC or proactive CV functionality is disabled, the 299 BFD session transitions to the ADMIN DOWN State and the BFD session 300 ends. 302 A new BFD session is initiated when the operator enables or re- 303 enables the CC or CV functionality on the same ME. 305 3.5. BFD Profile for MPLS-TP 307 BFD MUST operate in asynchronous mode. In this mode, the BFD Control 308 packets are periodically sent at configurable time rate. This rate is 309 typically a fixed value for the lifetime of the session. In the rare 310 circumstance where an operator has a reason to change session 311 parameters, poll/final discipline is used. 313 The transport profile is designed to operate independent of the 314 control plane; hence the C bit SHOULD be set. 316 This document specifies bi-directional BFD for p2p transport paths, 317 hence the M bit MUST be clear. 319 There are two modes of operation for bi-directional paths. One in 320 which both directions of the path fate share and one constructed from 321 BFD sessions in such a way that the two directions operate 322 independently. A single bi-directional BFD session is used for fate 323 sharing operation. Two independent BFD sessions are used for 324 independent operation. 326 Fate sharing operation is as described in [4]. Independent operation 327 requires clarification of two aspects of [4]. Independent operation 328 is characterized by the setting of MinRxInterval to zero by the MEP 329 that is typically the session originator, and there will be a session 330 originator at either end of the bi-directional path. 332 The base spec is unclear on aspects of how a session with a BFD 333 source set to zero interval behaves. One interpretation is that no 334 periodic messages originate with that source, it will only originate 335 messages on a state change. 337 The first clarification is that when a state change occurs a zero 338 interval source send BFD control messages with a one second period 339 until such time that the state change is confirmed by the session 340 peer. At this point the zero interval source can resume quiescent 341 behavior. This adds robustness to all state transitions in the 342 RxInterval=0 case. 344 The second is that the originating MEP (the one with a non-zero 345 TxInterval) will ignore a DOWN state received from a zero interval 346 peer. This means that the zero interval peer will continue to send 347 DOWN state messages as the state change is never confirmed. This adds 348 robustness to the exchange of RDI indication on a uni-directional 349 failure (for both session types DOWN with a diagnostic of control 350 detection period expired offering RDI functionality). 352 The normal usage is that 1:1 protected paths must use fate sharing, 353 and independent operation applies to 1+1 protected paths. 355 3.5.1. Session initiation 357 In all scenarios a BFD session starts with both ends in the DOWN 358 state. DOWN state messages exchanged include the desired Tx and Rx 359 rates for the session. If a node cannot support the Min Tx rate 360 desired by a peer MEP it does not transition from down to the INIT 361 state and sends a diagnostic code (TBD) indicating that the requested 362 Tx rate cannot be supported. 364 Otherwise once a transition from DOWN to INIT has occurred, the 365 session progresses as per [4]. 367 3.5.2. Defect entry criteria 369 There are further defect criteria beyond that defined in [4] to 370 consider given the possibility of mis-connectivity and mis- 371 configuration defects. The result is the criteria for a path 372 direction to transition from the defect free state to a defect state 373 is a superset of that in the BFD base specification [4]. 375 The following conditions case a MEP to enter the defect state: 376 1. BFD session times out (Loss of Continuity defect), 377 2. BFD control packets are received with an unexpected 378 encapsulation (Mis-connectivity defect), these include 379 - a PW receiving a packet with a GAL 380 - an LSP receiving an IP header instead of a GAL 381 (note there are other possibilities but these can also alias 382 3. Receipt of an unexpected globally unique Source MEP identifier 383 (Mis-connectivity defect), 384 4. Receipt of an unexpected session discriminator (Mis-connectivity 385 defect) 386 5. Receipt of an unexpected M bit (Session Mis-configuration 387 defect) 388 The effective defect hierarchy (order of checking) is 390 1. Receiving nothing 392 2. Receiving from an incorrect source (determined by whatever 393 means) 395 3. Receiving from a correct source (as near as can be determined), 396 but with incorrect session information) 398 4. Receiving control packets in all discernable ways correct. 400 3.5.3. Defect entry consequent action 402 Upon defect entry a sink MEP will assert signal fail into any client 403 (sub-)layers. It will also communicate session DOWN to its session 404 peer. 406 The blocking of traffic as consequent action MUST be driven only by a 407 defect's consequent action as specified in draft-ietf-mpls-tp-oam- 408 framework [6] section 5.1.1.2. 409 When the defect is mis-braching, the transport path termination will 410 silently discard all non-oam traffic received. 412 3.5.4. Defect exit criteria 414 Exit from a Loss of continuity defect 416 For a fate sharing session exit from a loss of connectivity defect is 417 as described in [4]. 419 For an independent session, exit from a loss of connectivity defect 420 occurs upon receipt of a well formed control packet from the peer 421 MEP. 423 Exit from a session mis-configuration defect 425 [editors: for a future version of the document] 427 Exit from a mis-connectivity defect 429 The exit criteria for a mis-connectivity defect is determined by the 430 maximum of the set of min Rx session time times the multiplier that 431 have been received. A session can transition from DOWN to UP 432 (independent mode) or DOWN to INIT (fate sharing mode) when both 433 correctly formed control packets are being exchanged, and no mis- 434 connected control packets have been received in the specified 435 interval. 437 3.5.5. Configuration of MPLS-TP BFD sessions 439 [Editors note, for a future revision of the document] 441 3.5.6. Discriminator values 443 MPLS labels at peer MEPs are used to provide context for the received 444 BFD packets. 446 In the BFD control packet the discriminator values have either local 447 or no significance. 449 My Discriminator field MUST be set to a nonzero value (it can be a 450 fixed value), the transmitted your discriminator value MUST reflect 451 back the received value of My discriminator field or be set to 0 if 452 that value is not known. 454 4. Acknowledgments 456 To be added in a later version of this document 458 5. IANA Considerations 460 To be added in a later version of this document 462 6. Security Considerations 464 The security considerations for the authentication TLV need further 465 study. 467 Base BFD foresees an optional authentication section (see [4] 468 section 6.7); that can be extended also to the tool proposed in 469 this document. 471 Authentication methods that require checksum calculation on the 472 outgoing packet must extend the checksum also on the ME 473 Identifier Section. This is possible but seems uncorrelated with 474 the solution proposed in this document: it could be better to 475 use the simple password authentication method. 477 7. References 479 7.1. Normative References 481 [1] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC 485 5586 , June 2009 487 [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for 488 OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam- 489 requirements-06 (work in progress), March 2010 491 [4] Katz, D. and D. Ward, "Bidirectional Forwarding 492 Detection", draft-ietf-bfd-base-11 (work in progress), 493 February 2009 495 [5] Boutros, S. et al., "Definition of ACH TLV Structure", 496 draft-ietf-mpls-tp-ach-tlv-02 (work in progress), March 497 2010 499 7.2. Informative References 501 [6] Bocci, M., et al., "A Framework for MPLS in Transport 502 Networks", draft-ietf-mpls-tp-framework-12, (work in 503 progress), May 2010 505 [7] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- 506 swallow-mpls-tp-identifiers-02 (work in progress), March 507 2010 509 [8] Allan, D., Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM 510 Framework", draft-ietf-mpls-tp-oam-framework-06 (work in 511 progress), April 2010 513 Authors' Addresses 515 Dave Allan 516 Ericsson 517 Email: david.i.allan@ericsson.com 519 John Drake 520 Juniper 521 Email: jdrake@juniper.net 523 George Swallow 524 Cisco Systems, Inc. 525 Email: swallow@cisco.com 527 Annamaria Fulignoli 528 Ericsson 529 Email: annamaria.fulignoli@ericsson.com 531 Sami Boutros 532 Cisco Systems, Inc. 533 Email: sboutros@cisco.com 535 Martin Vigoureux 536 Alcatel-Lucent 537 Email: martin.vigoureux@alcatel-lucent.com 539 Siva Sivabalan 540 Cisco Systems, Inc. 541 Email: msiva@cisco.com 543 David Ward 544 Juniper 545 Email: dward@juniper.net