idnits 2.17.1 draft-ietf-mpls-tp-cc-cv-rdi-06.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 (August 2011) is 4636 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 (-07) exists of draft-ietf-mpls-tp-fault-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-06 ** Obsolete normative reference: RFC 5226 (ref. '11') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 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: February 2012 George Swallow Ed. 5 Cisco Systems, Inc 7 John Drake Ed. 8 Juniper 10 August 2011 12 Proactive Connectivity Verification, Continuity Check and Remote 13 Defect indication for MPLS Transport Profile 14 draft-ietf-mpls-tp-cc-cv-rdi-06 16 Abstract 18 Continuity Check, Proactive Connectivity Verification and Remote 19 Defect Indication functionalities are required for MPLS-TP OAM. 21 Continuity Check monitors a label switched path for any loss-of- 22 continuity defect. Connectivity Verification augments Continuity 23 Check in order to provide confirmation that the desired source is 24 connected to the desired sink. Remote defect indication enables an 25 End Point to report, to its associated End Point, a fault or defect 26 condition that it detects on a pseudo wire, label switched path or 27 Section. 29 This document specifies specific extensions to BFD and methods for 30 proactive Continuity Check, Continuity Verification, and Remote 31 Defect Indication for MPLS-TP label switched paths, pseudo wires and 32 Sections using Bidirectional Forwarding Detection as extended by 33 this memo. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC2119 [1]. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance 44 with the provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet 47 Engineering Task Force (IETF), its areas, and its working 48 groups. Note that other groups may also distribute working 49 documents as Internet-Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six 52 months and may be updated, replaced, or obsoleted by other 53 documents at any time. It is inappropriate to use Internet- 54 Drafts as reference material or to cite them other than as "work 55 in progress". 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt. 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html. 63 This Internet-Draft will expire on February 9th, 2012. 65 Copyright Notice 67 Copyright (c) 2011 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with 75 respect to this document. Code Components extracted from this 76 document must include Simplified BSD License text as described 77 in Section 4.e of the Trust Legal Provisions and are provided 78 without warranty as described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction...................................................3 83 2. Conventions used in this document..............................4 84 2.1. Terminology..................................................4 85 3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD...........5 86 3.1. Existing Capabilities........................................5 87 3.2. CC, CV, and RDI Overview.....................................6 88 3.3. ACH code points for CC and proactive CV......................7 89 3.4. MPLS-TP BFD CC Message format................................7 90 3.5. MPLS-TP BFD proactive CV Message format......................8 91 3.5.1. Section MEP-ID.............................................9 92 3.5.2. LSP MEP-ID................................................10 93 3.5.3. PW Endpoint MEP-ID........................................10 94 3.6. BFD Session in MPLS-TP terminology..........................11 95 3.7. BFD Profile for MPLS-TP.....................................12 96 3.7.1. Session initiation and Modification.......................13 97 3.7.2. Defect entry criteria.....................................13 98 3.7.3. Defect entry consequent action............................15 99 3.7.4. Defect exit criteria......................................15 100 3.7.5. State machines............................................15 101 3.7.6. Configuration of MPLS-TP BFD sessions.....................18 102 3.7.7. Discriminator values......................................18 103 4. Configuration Considerations..................................18 104 5. Acknowledgments...............................................19 105 6. IANA Considerations...........................................19 106 7. Security Considerations.......................................20 107 8. References....................................................20 108 8.1. Normative References........................................20 109 8.2. Informative References......................................21 111 1. Introduction 113 In traditional transport networks, circuits are provisioned on two or 114 more switches. Service Providers (SP) need Operations, Administration 115 and Maintenance (OAM) tools to detect mis-connectivity and loss-of- 116 continuity of transport circuits. Both pseudo wires (PWs) and MPLS-TP 117 label switched paths (LSPs) [12] emulating traditional transport 118 circuits need to provide the same Continuity Check (CC), proactive 119 Continuity Verification (CV), and Remote Defect Indication (RDI) 120 capabilities as required in RFC 5860[3]. This document describes the 121 use of Bidirectional Forwarding Detection (BFD)[4] for CC, proactive 122 CV, and RDI of a PW, LSP or sub-path maintenance entity (SPME) 123 between two Maintenance Entity Group End Points (MEPs). 125 As described in [13], CC and CV functions are used to detect loss-of- 126 continuity (LOC), and unintended connectivity between two MEPs (e.g. 127 mis-merging or mis-connectivity or unexpected MEP). 129 RDI is an indicator that is transmitted by a MEP to communicate to 130 its peer MEP that a signal fail condition exists. RDI is only used 131 for bidirectional LSPs and is associated with proactive CC & CV BFD 132 control packet generation. 134 This document specifies the BFD extension and behavior to satisfy the 135 CC, proactive CV monitoring and the RDI functional requirements for 136 both co-routed and associated bi-directional LSPs. Supported 137 encapsulations include generic alert label (GAL)/generic associated 138 channel (G-ACh), virtual circuit connectivity verification (VCCV) and 139 UDP/IP. Procedures for uni-directional point-to-point (p2p) and 140 point-to-multipoint (p2mp) LSPs are for further study. 142 This document utilizes identifiers for MPLS-TP systems as defined in 143 [9]. Work is on-going in the ITU-T to define a globally-unique 144 semantic for ITU Carrier Codes (ICCs), and future work may extend 145 this document to utilize ICCs as identifiers for MPLS-TP systems. 147 The mechanisms specified in this document are restricted to BFD 148 asynchronous mode. 150 2. Conventions used in this document 152 2.1. Terminology 154 ACH: Associated Channel Header 156 BFD: Bidirectional Forwarding Detection 158 CC: Continuity Check 160 CV: Connectivity Verification 162 GAL: G-ACh Label 164 G-ACh: Generic Associated Channel 166 LDI: Link Down Indication 168 LKI: Lock Instruct 170 LKR: Lock Report 172 LSP: Label Switched Path 174 LSR: Label Switching Router 176 ME: Maintenance Entity 178 MEG: Maintenance Entity Group 180 MEP: Maintenance Entity Group End Point 182 MIP: Maintenance Entity Group Intermediate Point 183 MPLS: Multi-Protocol Label Switching 185 MPLS-OAM: MPLS Operations, Administration and Maintenance 187 MPLS-TP: MPLS Transport Profile 189 MPLS-TP LSP: Uni-directional or Bidirectional Label Switched Path 190 representing a circuit 192 MS-PW: Multi-Segment PseudoWire 194 NMS: Network Management System 196 OAM: Operations, Administration, and Maintenance [14] 198 PW: Pseudo Wire 200 PDU: Protocol Data Unit 202 P/F: Poll-Final 204 RDI: Remote Defect Indication 206 SPME: Sub-Path Maintenance Entity 208 TTL: Time To Live 210 TLV: Type Length Value 212 VCCV: Virtual Circuit Connectivity Verification 214 3. MPLS-TP CC, proactive CV and RDI Mechanism using BFD 216 This document describes procedures for achieve combined CC, CV and 217 RDI functionality within a single MPLS-TP MEG using BFD. This 218 augments the capabilities that can be provided for MPLS-TP LSPs using 219 existing specified tools and procedures. 221 3.1. Existing Capabilities 223 A CC-only mode may be provided via protocols and procedures described 224 in RFC 5885[7] with ACH channel 7. These procedures may be applied to 225 bi-directional LSPs (via the use of the GAL), as well as PWs. 227 Implementations may also interoperate with legacy equipment by 228 implementing RFC 5884[8] for LSPs and RFC 5085[10] for PWs, in 229 addition to the procedures documented in this memo. In accordance 230 with RFC 5586[2], when BFD control packets are encapsulated in an IP 231 header, the fields in the IP header are set as defined in RFC 232 5884[8]. When IP encapsulation is used CV mis-connectivity defect 233 detection can be performed by inferring a globally unique source on 234 the basis of the combination of the source IP address and My 235 Discriminator" fields. 237 3.2. CC, CV, and RDI Overview 239 The combined CC, CV, and RDI functionality for MPLS-TP is achieved by 240 multiplexing CC and CV PDUs within a single BFD session. The CV PDUs 241 are augmented with a source MEP ID TLV to permit mis-connectivity 242 detection to be performed by sink MEPs. 244 The interleaving of PDUs is achieved via the use of distinct 245 encapsulations and code points for generic associated channel (G-ACh) 246 encapsulated BFD depending on whether the PDU format is CC or CV: 248 o CC format: defines a new code point in the Associated Channel 249 Header (ACH) described in RFC 5586[2].This format supports 250 Continuity Check and RDI functionalities. 252 o CV format: defines a new code point in the Associated Channel 253 Header (ACH) described in RFC 5586[2]. The ACH with "MPLS-TP 254 Proactive CV" code point indicates that the message is an MPLS-TP 255 BFD proactive CV message, and information for CV processing is 256 appended in the form of the source MEP ID TLV. 258 RDI is communicated via the BFD diagnostic field in BFD CC messages, 259 and the diagnostic code field in CV messages MUST be ignored. It is 260 not a distinct PDU. As per [4], a sink MEP SHOULD encode a diagnostic 261 code of "1 - Control detection time expired" when the interval times 262 detect multiplier have been exceeded. A sink MEP SHOULD encode a 263 diagnostic code of "5 - Path Down" as a consequence of the sink MEP 264 receiving LDI. A sink MEP MUST encode a diagnostic code of "XX - 265 - 266 Misconnectivity defect" (to be assigned by IANA) when CV PDU 267 processing indicates a misconnectivity defect. A sink MEP that has 268 started sending diagnostic code 5 SHOULD NOT change it to 1 when the 269 detection timer expires. 271 3.3. ACH code points for CC and proactive CV 273 Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI 274 functionality. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |0 0 0 1|Version| Flags | BFD CC/CV Code Point | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 1: ACH Indication of MPLS-TP CC/CV/RDI 284 The first nibble (0001b) indicates the G-ACh as per RFC 5586[2]. 286 The version and the flags are set to 0 as specified in [2]. 288 The code point is either 290 - BFD CC code point = XX1. [XX1 to be assigned by IANA from the PW 291 Associated Channel Type registry.] or, 293 - BFD proactive CV code point = XX2. [XX2 to be assigned by IANA from 294 the PW Associated Channel Type registry.] 296 CC and CV PDUs apply to all pertinent MPLS-TP structures, including 297 PWs, MPLS LSPs (including SPMEs), and Sections. 299 CC and CV operation is simultaneously employed on a maintenance 300 entity (ME) within a single BFD session. The expected usage is that 301 normal operation is to send CC BFD protocol data units (PDUs) 302 interleaved with a CV BFD PDU (augmented with a source MEP-ID and 303 identified as requiring additional processing by the different ACh 304 channel type). The insertion interval for CV PDUs is one per second. 305 Detection of a loss-of-continuity defect is the detect multiplier 306 (fixed at 3 for the CC code point) times the session periodicity. 307 Mis-connectivity defects are detected in a maximum of one second. 308 3.4. MPLS-TP BFD CC Message format 310 The format of an MPLS-TP CC Message is shown below. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |0 0 0 1|Version| Flags | BFD CC Code point | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 ~ BFD Control Packet ~ 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2: MPLS-TP CC Message 323 As shown in figure 2, the MPLS-TP CC message consists of the BFD 324 control packet as defined in [4] pre-pended by the G-ACh. 326 3.5. MPLS-TP BFD proactive CV Message format 328 The format of an MPLS-TP CV Message is shown below. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |0 0 0 1|Version| Flags | BFD CV Code Point | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 ~ BFD Control Packet ~ 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 ~ MEP Source ID TLV ~ 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 3: MPLS-TP CV Message 346 As shown in figure 3, the MPLS-TP CV message consists of the BFD 347 control packet as defined in [4] pre-pended by the ACH, and appended 348 by a MEP source ID TLV. 350 A MEP Source ID TLV is encoded as a 2 octet field that specifies a 351 Type, followed by a 2 octet Length Field, followed by a variable 352 length Value field. A BFD session will only use one encoding of the 353 Source ID TLV. 355 The length in the BFD control packet is as per [4]; the length of the 356 MEP Source ID TLV is not included. There are 3 possible Source MEP 357 TLVs (corresponding to the MEP-IDs defined in [9]) [type fields to be 358 assigned by IANA]. The type fields are: 360 X1 - Section MEP-ID 362 X2 - LSP MEP-ID 364 X3 - PW MEP-ID 366 When GAL label is used, the time to live (TTL) field of the GAL MUST 367 be set to at least 1, and the GAL MUST be the end of stack label 368 (S=1) as per [2]. 370 A node MUST NOT change the value in the MEP Source ID TLV. 372 When digest based authentication is used, the Source ID TLV MUST NOT 373 be included in the digest 375 3.5.1. Section MEP-ID 377 The IP compatible MEP-IDs for MPLS-TP sections is the interface ID. 378 The format of the Section MEP-ID TLV is: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | MPLS-TP Global_ID | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | MPLS-TP Node Identifier | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | MPLS-TP Interface Number | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 4: Section MEP-ID TLV format 394 Where the type is of value 'X1' (to be assigned by IANA). The length 395 is the length of the value fields. The MPLS-TP Global ID, Node 396 Identifier and Interface Numbers are as per [9]. 398 3.5.2. LSP MEP-ID 400 The fields for the LSP MEP-ID is as defined in [9]. This is 401 applicable to both LSPs and SPMEs. This consists of 32-bit MPLS-TP 402 Global ID, the 32-bit Node Identifier, followed by the 16-bit 403 Tunnel_Num (that MUST be unique within the context of the Node 404 Identifier), and the 16-bit LSP_NUM (that MUST be unique with the 405 context of the Tunnel Num). The format of the TLV is: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | MPLS-TP Global_ID | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | MPLS-TP Node Identifier | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Tunnel_Num | LSP_Num | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: LSP MEP-ID TLV format 421 Where the type is of value 'X2' (to be assigned by IANA). The length 422 is the length of the value fields. The MPLS-TP Global ID, Node 423 Identifier, Tunnel Num and LSP_Num are as per [9]. 425 3.5.3. PW Endpoint MEP-ID 427 The fields for the MPLS-TP PW Endpoint MEP-ID is as defined in [9]. 428 The format of the TLV is: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Length | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | MPLS-TP Global_ID | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | MPLS-TP Node Identifier | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | AC_ID | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | AGI Type | AGI Length | AGI Value | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 ~ AGI Value (contd.) ~ 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 6: PW Endpoint MEP-ID TLV format 449 Where the type is value 'X3' (to be assigned by IANA). The length is 450 the length of the following data. The Global ID, Node Identifier and 451 Attachment Circuit (AC)_ID are as per [9]. The Attachment Group 452 Identifier (AGI) Type is as per [6], and the AGI length is the length 453 of the AGI value field. 455 3.6. BFD Session in MPLS-TP terminology 457 A BFD session corresponds to a CC and proactive CV OAM instance in 458 MPLS-TP terminology. A BFD session is enabled when the CC and 459 proactive CV functionality is enabled on a configured Maintenance 460 Entity (ME). 462 When the CC and proactive CV functionality is disabled on an ME, the 463 BFD session transitions to the ADMIN DOWN State and the BFD session 464 ends. 466 A new BFD session is initiated when the operator enables or re- 467 enables the CC and CV functionality. 469 All BFD state changes and P/F exchanges MUST be done using CC 470 packets. P/F and session state information in CV packets MUST be 471 ignored. 473 3.7. BFD Profile for MPLS-TP 475 BFD operates in asynchronous mode utilizing the encapsulation defined 476 in section 3 for all sessions in a given MEG. For LSPs, SPMEs and 477 sections this is GAL/G-ACh encapsulated BFD using the code points 478 specified in section 3.3. For PWs, this is G-ACh or GAL/G-ACh 479 encapsulated BFD using the code points specified in section 3.3. In 480 this mode, the BFD Control packets are periodically sent at 481 configurable time rate. This rate is a fixed value common for both 482 directions of MEG for the lifetime of the MEG. 484 This document specifies bi-directional BFD for p2p transport LSPs; 485 hence all BFD packets MUST be sent with the M bit clear. 487 There are two modes of operation for bi-directional LSPs. One in 488 which the session state of both directions of the LSP is coordinated 489 and one constructed from BFD sessions in such a way that the two 490 directions operate independently but are still part of the same MEG. 491 A single bi-directional BFD session is used for coordinated 492 operation. Two independent BFD sessions are used for independent 493 operation. It should be noted that independent operation treats 494 session state and defect state as independent entities. For example 495 an independent session can be in the UP state while receiving RDI 496 indication. For a coordinated session, the session state will track 497 the defect state. 499 In coordinated mode, an implementation SHOULD NOT reset 500 bfd.RemoteDiscr until it is exiting the DOWN state. 502 In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr 503 upon transitioning to the DOWN state. 505 Overall operation is as specified in [4] and augmented for MPLS in 506 [8]. Coordinated operation is as described in [4]. Independent 507 operation requires clarification of two aspects of [4]. Independent 508 operation is characterized by the setting of bfd.MinRxInterval to 509 zero by the MEP that is typically the session originator (referred to 510 as the source MEP), and there will be a session originator at either 511 end of the bi-directional LSP. Each source MEP will have a 512 corresponding sink MEP that has been configured to a Tx interval of 513 zero. 515 This memo specifies a preferred interpretation of the base spec on 516 how a MEP with a BFD transmit rate set to zero behaves. One 517 interpretation is that no periodic messages on the reverse component 518 of the bi-directional LSP originate with that MEP, it will only 519 originate messages on a state change. 521 The first clarification is that when a state change occurs a MEP set 522 to a transmit rate of zero sends BFD control messages with a one 523 second period on the reverse component until such time that the state 524 change is confirmed by the session peer. At this point the MEP set to 525 a transmit rate of zero can resume quiescent behavior. This adds 526 robustness to all state transitions in the RxInterval=0 case. 528 The second is that the originating MEP (the one with a non-zero 529 bfd.TxInterval) will ignore a DOWN state received from a zero 530 interval peer. This means that the zero interval peer will continue 531 to send DOWN state messages that include the RDI diagnostic code as 532 the state change is never confirmed. This adds robustness to the 533 exchange of RDI indication on a uni-directional failure (for both 534 session types DOWN with a diagnostic of either control detection 535 period expired or neighbor signaled session down offering RDI 536 functionality). 538 A further extension to the base specification is that there are 539 additional OAM protocol exchanges that act as inputs to the BFD state 540 machine; these are the Link Down Indication [5] and the Lock 541 Instruct/Lock Report transactions; Lock Report interaction being 542 optional. 544 3.7.1. Session initiation and Modification 546 Session initiation occurs starting from MinRx = 1 second, MinTx >= 1 547 second and the detect multiplier = 3. 548 Once in the UP state, poll/final discipline is used to modify the 549 periodicity of control message exchange from their default rates to 550 the desired rates and set the detect multiplier to 3. 551 Once the desired rate has been reached using the poll/final 552 mechanism, implementations SHOULD NOT attempt further rate 553 modification. 554 In the rare circumstance where an operator has a reason to further 555 change session parameters, beyond the initial migration from default 556 values; poll/final discipline can be used with the caveat that a peer 557 implementation may consider a session change unacceptable and/or 558 bring the BFD session down via the use of the ADMIN DOWN state. 560 3.7.2. Defect entry criteria 562 There are further defect criteria beyond those that are defined in 563 [4] to consider given the possibility of mis-connectivity defects. 564 The result is the criteria for a LSP direction to transition from the 565 defect free state to a defect state is a superset of that in the BFD 566 base specification [4]. 568 The following conditions cause a MEP to enter the defect state for CC 569 PDUs (in no particular order): 570 1. BFD session times out (loss-of-continuity defect). 571 2. Receipt of a link down indication or lock report. 573 And the following will cause the MEP to enter the mis-connectivity 574 defect state for CV operation (again not in any particular order): 575 1. BFD control packets are received with an unexpected 576 encapsulation (mis-connectivity defect), these include: 577 - receiving an IP encoded CC or CV BFD control packet on a 578 LSP configured to use GAL/G-ACh, or vice versa 579 (note there are other possibilities that can also alias as an 580 OAM packet) 581 2. Receipt of an unexpected globally unique Source MEP identifier 582 (Mis-connectivity defect). Note that as each encoding of the 583 Source MEP ID TLV contains unique information (there is no 584 mechanical translation possible between MEP ID formats), receipt 585 of an unexpected source MEP ID type is the same as receiving an 586 unexpected value. 587 3. Receipt of a session discriminator that is not in the local BFD 588 database in the Your Discriminator field (mis-connectivity 589 defect). 590 4. Receipt of a session discriminator that is in the local database 591 but does not have the expected label (mis-connectivity defect). 592 5. IF BFD authentication is used, receipt of a message with 593 incorrect authentication information (password, MD5 digest, or 594 SHA1 hash). 596 The effective defect hierarchy (order of checking) is 598 1. Receiving nothing. 600 2. Receiving link down indication. E.g. a local link failure, an 601 MPLS-TP LDI indication, or Lock Report. 603 3. Receiving from an incorrect source (determined by whatever 604 means). 606 4. Receiving from a correct source (as near as can be determined), 607 but with incorrect session information). 609 5. Receiving BFD control packets in all discernable ways correct. 611 3.7.3. Defect entry consequent action 613 Upon defect entry a sink MEP will assert signal fail into any client 614 (sub-)layers. It will also communicate session DOWN to its session 615 peer using CC messages. 617 The blocking of traffic as a consequent action MUST be driven only by 618 a defect's consequent action as specified in [13] section 5.1.1.2. 620 When the defect is mis-connectivity, the section, LSP or PW 621 termination will silently discard all non-OAM traffic received. The 622 sink MEP will also send a defect indication back to the source MEP 623 via the use of a diagnostic code of mis-connectivity defect to be 624 assigned by IANA. 626 3.7.4. Defect exit criteria 628 3.7.4.1. Exit from a loss-of-continuity defect 630 For a coordinated session, exit from a loss-of-connectivity defect is 631 as described in figure 7 which updates [4]. 633 For an independent session, exit from a loss-of-connectivity defect 634 occurs upon receipt of a well formed BFD control packet from the peer 635 MEP as described in figures 8 and 9. 637 3.7.4.2. Exit from a mis-connectivity defect 639 Exit from a mis-connectivity defect state occurs when no CV messages 640 with mis-connectivity defects have been received for a period of 3.5 641 seconds. 643 3.7.5. State machines 645 The following state machines update [4]. They have been modified to 646 include LDI and LKR as specified in [5] as inputs to the state 647 machine and to clarify the behavior for independent mode. LKR is an 648 optional input. 650 The coordinated session state machine has been augmented to indicate 651 LDI and optionally LKR as inputs to the state machine. For a session 652 that is in the UP state, receipt of LDI or optionally LKR will 653 transition the session into the DOWN state. 655 +--+ 656 | | UP, ADMIN DOWN, TIMER, LDI, LKR 657 | V 658 DOWN +------+ INIT 659 +------------| |------------+ 660 | | DOWN | | 661 | +-------->| |<--------+ | 662 | | +------+ | | 663 | | MISCONNECTIVITY,| | 664 | | ADMIN DOWN,| | 665 | |ADMIN DOWN, DOWN,| | 666 | |TIMER TIMER,| | 667 V |LDI,LKR LDI,LKR | V 668 +------+ +------+ 669 +----| | | |----+ 670 DOWN| | INIT |--------------------->| UP | |INIT, UP 671 +--->| | INIT, UP | |<---+ 672 +------+ +------+ 674 Figure 7: MPLS CC state machine for coordinated session operation 676 For independent mode, there are two state machines. One for the 677 source MEP (which requested bfd.MinRxInterval=0) and the sink MEP 678 (which agreed to bfd.MinRxInterval=0). 680 The source MEP will not transition out of the UP state once 681 initialized except in the case of a forced ADMIN DOWN. Hence LDI and 682 optionally LKR do not enter into the state machine transition from 683 the UP state, but do enter into the INIT and DOWN states. 685 +--+ 686 | | UP, ADMIN DOWN, TIMER, LDI, LKR 687 | V 688 DOWN +------+ INIT 690 +------------| |------------+ 691 | | DOWN | | 692 | +-------->| |<--------+ | 693 | | +------+ | | 694 | | | | 695 | |ADMIN DOWN ADMIN DOWN | | 696 | |TIMER, | | 697 | |LDI, | | 698 V |LKR | V 699 +------+ +------+ 700 +----| | | |----+ 701 DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, 702 +--->| | INIT, UP | |<---+ LDI, LKR 703 +------+ +------+ 705 Figure 8: MPLS CC State machine for source MEP for independent 706 session operation 708 The sink MEP state machine (for which the transmit interval has been 709 set to zero) is modified to: 711 1) Permit direct transition from DOWN to UP once the session has been 712 initialized. With the exception of via the ADMIN DOWN state, the 713 source MEP will never transition from the UP state, hence in normal 714 unidirectional fault scenarios will never transition to the INIT 715 state. 717 +--+ 718 | | ADMIN DOWN, TIMER, LDI, LKR 719 | V 720 DOWN +------+ INIT, UP 721 +------------| |------------+ 722 | | DOWN | | 723 | +-------->| |<--------+ | 724 | | +------+ | | 725 | | MISCONNECTIVITY,| | 726 | | ADMIN DOWN,| | 727 | |ADMIN DOWN, TIMER, | | 728 | |TIMER, DOWN, | | 729 | |LDI, LDI, | V 730 V |LKR LKR | | 731 +------+ +------+ 732 +----| | | |----+ 733 DOWN| | INIT |--------------------->| UP | |INIT, UP 734 +--->| | INIT, UP | |<---+ 735 +------+ +------+ 737 Figure 9: MPLS CC State machine for the sink MEP for independent 738 session operation 740 3.7.6. Configuration of MPLS-TP BFD sessions 742 Configuration of MPLS-TP BFD session parameters and coordination of 743 same between the source and sink MEPs is out of scope of this memo. 745 3.7.7. Discriminator values 747 In the BFD control packet the discriminator values have either local 748 to the sink MEP or no significance (when not known). 750 My Discriminator field MUST be set to a nonzero value (it can be a 751 fixed value), the transmitted Your Discriminator value MUST reflect 752 back the received value of My Discriminator field or be set to 0 if 753 that value is not known. 755 Per RFC5884 Section 7 [8], a node MUST NOT change the value of the My 756 Discriminator" field for an established BFD session. 758 4. Configuration Considerations 760 The following is an example set of configuration parameters for a BFD 761 session: 763 Mode and Encapsulation 764 RFC 5884 - BFD CC in UDP/IP/LSP 765 RFC 5885 - BFD CC in G-ACh 766 RFC 5085 - UDP/IP in G-ACh 767 MPLS-TP - CC/CV in GAL/G-ACh or G-ACh 769 For MPLS-TP, the following additional parameters need to be 770 configured: 771 1) Session mode, coordinated or independent 772 2) CC periodicity 773 3) The MEP ID for the MEPs at either end of the LSP 774 4) Whether authentication is enabled (and if so, the associated 775 parameters) 777 And the the discriminators used by each MEP, both bfd.LocalDiscr and 778 bfd.RemoteDiscr can optionally be configured or locally assigned. 779 Finally a detect multiplier of 3 is directly inferred from the code 780 points. 782 5. Acknowledgments 784 Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher and Yaacov 785 Weingarten also contributed to this document. 787 6. IANA Considerations 789 This draft requires the allocation of two channel types from the IANA 790 "PW Associated Channel Type" registry in RFC4446 [6]. 791 XX1 MPLS-TP CC message 792 XX2 MPLS-TP CV message 793 This draft requires the creations of a source MEP-ID TLV 794 registry. The parent registry will be the "PW Associated Channel 795 Type" registry of RFC4446 [6]. All code points within this 796 registry shall be allocated according to the "Standards Action" 797 procedures as specified in [11]. 799 The initial values are: 801 X1 - Section MEP-ID 803 X2 - LSP MEP-ID 804 X3 - PW MEP-ID 806 The items tracked in the registry will be the type, and the 807 associated name and reference. The source MEP-ID TLV will require 808 standards action registration procedures for additional values. 810 This memo requests a code point from the registry for BFD 811 diagnostic codes [4]: 813 XX - 814 - mis-connectivity defect 816 7. Security Considerations 818 The use of CV improves network integrity by ensuring traffic is 819 not "leaking" between LSPs. 821 Base BFD foresees an optional authentication section (see [4] 822 section 6.7); that can be applied to this application. Although 823 the source MEP-ID TLV is not included in the BFD authentication 824 digest, there is a chain of trust such that the discriminator 825 associated with the digest is also associated with the expected 826 MEP-ID which will prevent impersonation of CV messages in this 827 application. 829 This memo specifies the use of globally unique identifiers for 830 MEP IDs. This provides absolutely authoritative detection of 831 persistent leaking of traffic between LSPs. Non-uniqueness can 832 result in undetected leaking in the scenario where two LSPs with 833 common MEP IDs are misconnected. This would be considered to be 834 undesirable but rare, it would also be difficult to exploit for 835 malicious purposes as at a minimum, both a network end point, 836 and a node that was a transit point for the target MEG would 837 need to be compromised. 839 8. References 841 8.1. Normative References 843 [1] Bradner, S., "Key words for use in RFCs to Indicate 844 Requirement Levels", BCP 14, RFC 2119, March 1997. 846 [2] Bocci, M. et al., "MPLS Generic Associated Channel ", RFC 847 5586 , June 2009 849 [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for 850 Operations Administration and Maintenance in MPLS 851 Transport Networks", RFC5860, May 2010 853 [4] Katz, D. and D. Ward, "Bidirectional Forwarding 854 Detection", RFC 5880, June 2010 856 [5] Swallow, G. et al., "MPLS Fault Management OAM", draft- 857 ietf-mpls-tp-fault-04 (work in progress), April 2011 859 [6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 860 Emulation (PWE3)", RFC 4446, April 2006 862 [7] Nadeau, T. et al. "Bidirectional Forwarding Detection 863 (BFD) for the Pseudowire Virtual Circuit Connectivity 864 Verification (VCCV) ", IETF RFC 5885, June 2010 866 [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection 867 (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, 868 June 2010 870 [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- 871 ietf-mpls-tp-identifiers-06 (work in progress), June 2011 873 [10] Nadeau, T, et al., "Pseudowire Virtual Circuit 874 Connectivity Verification (VCCV): A Control Channel for 875 Pseudowires", RFC 5085, December 2007 877 [11] Narten, T., Alvestrand, H., "Guidelines for Writing an 878 IANA Considerations Section in RFCs", IETF RFC 5226, May 879 2008 881 8.2. Informative References 883 [12] Bocci, M., et al., "A Framework for MPLS in Transport 884 Networks", RFC5921, July 2010 886 [13] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- 887 ietf-mpls-tp-oam-framework-11 (work in progress), February 888 2011 890 [14] Andersson et. al., "OAM Terminology", IETF RFC 6291, June 891 2011 893 Authors' Addresses 895 Dave Allan 896 Ericsson 897 Email: david.i.allan@ericsson.com 899 John Drake 900 Juniper 901 Email: jdrake@juniper.net 903 George Swallow 904 Cisco Systems, Inc. 905 Email: swallow@cisco.com 907 Annamaria Fulignoli 908 Ericsson 909 Email: annamaria.fulignoli@ericsson.com 911 Sami Boutros 912 Cisco Systems, Inc. 913 Email: sboutros@cisco.com 915 Martin Vigoureux 916 Alcatel-Lucent 917 Email: martin.vigoureux@alcatel-lucent.com 919 Siva Sivabalan 920 Cisco Systems, Inc. 921 Email: msiva@cisco.com 923 David Ward 924 Juniper 925 Email: dward@juniper.net 927 Robert Rennison 928 ECI Telecom 929 Email: robert.rennison@ecitele.com