idnits 2.17.1 draft-ietf-mpls-tp-cc-cv-rdi-03.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 (February 2, 2011) is 4831 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-03 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-identifiers-03 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-10 Summary: 0 errors (**), 0 flaws (~~), 4 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: August 2011 George Swallow Ed. 5 Cisco Systems, Inc 7 John Drake Ed. 8 Juniper 10 February 2, 2011 12 Proactive Connectivity Verification, Continuity Check and Remote 13 Defect indication for MPLS Transport Profile 14 draft-ietf-mpls-tp-cc-cv-rdi-03 16 Abstract 18 Continuity Check (CC), Proactive Connectivity Verification (CV) and 19 Remote Defect Indication (RDI) functionalities are required for MPLS- 20 TP OAM. 22 Continuity Check monitors the integrity of the continuity of the LSP 23 for any loss of continuity defect. Connectivity verification monitors 24 the integrity of the routing of the LSP 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 August 2nd 2011. 63 Copyright Notice 65 Copyright (c) 2011 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......................................................4 82 2. Conventions used in this document..............................4 83 2.1. Terminology..................................................4 84 3. MPLS CC, proactive CV and RDI Mechanism using BFD..............5 85 3.1. ACH code points for CC and proactive CV......................6 86 3.2. MPLS BFD CC Message format...................................6 87 3.3. MPLS BFD proactive CV Message format.........................7 88 3.3.1. ICC-based MEP-ID...........................................8 89 3.3.2. LSP MEP-ID.................................................8 90 3.3.3. PW Endpoint MEP-ID.........................................8 91 3.4. BFD Session in MPLS-TP terminology...........................8 92 3.5. BFD Profile for MPLS-TP......................................9 93 3.5.1. Session initiation........................................10 94 3.5.2. Defect entry criteria.....................................10 95 3.5.3. Defect entry consequent action............................11 96 3.5.4. Defect exit criteria......................................12 97 3.5.5. State machines............................................12 98 3.5.6. Configuration of MPLS-TP BFD sessions.....................15 99 3.5.7. Discriminator values......................................15 100 4. Acknowledgments...............................................16 101 5. IANA Considerations...........................................16 102 6. Security Considerations.......................................16 103 7. References....................................................16 104 7.1. Normative References........................................16 105 7.2. Informative References......................................17 107 1. Introduction 109 In traditional transport networks, circuits are provisioned on two or 110 more switches. Service Providers (SP) need OAM tools to detect mis- 111 connectivity and loss of continuity of transport circuits. Both PWs 112 and MPLS-TP LSPs [10] emulating traditional transport circuits need 113 to provide the same CC and proactive CV capabilities as required in 114 RFC 5860[3]. This document describes the use of BFD for CC, proactive 115 CV, and RDI of a PW, LSP or SPME between two Maintenance Entity Group 116 End Points (MEPs). 118 As described in [11], Continuity Check (CC) and Proactive 119 Connectivity Verification (CV) functions are used to detect loss of 120 continuity (LOC), and unintended connectivity between two MEPs (e.g. 121 mismerging or misconnectivity or unexpected MEP). 123 The Remote Defect Indication (RDI) is an indicator that is 124 transmitted by a MEP to communicate to its peer MEP that a signal 125 fail condition exists. RDI is only used for bidirectional LSPs and is 126 associated with proactive CC & CV packet generation. 128 This document specifies the BFD extension and behavior to satisfy the 129 CC, proactive CV monitoring and the RDI functional requirements for 130 both co-routed and associated bi-directional LSPs. Supported 131 encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for 132 uni-directional LSPs are for further study. 134 The mechanisms specified in this document are restricted to BFD 135 asynchronous mode. 137 1.1. Authors 139 David Allan, John Drake, George Swallow, Annamaria Fulignoli, Sami 140 Boutros, Siva Sivabalan, David Ward, Martin Vigoureux. 142 2. Conventions used in this document 144 2.1. Terminology 146 ACH: Associated Channel Header 148 BFD: Bidirectional Forwarding Detection 150 CV: Connectivity Verification 152 GAL: Generalized Alert Label 154 LDI: Link Down Indication 156 LKI: Lock Instruct 158 LKR: Lock Report 160 LSR: Label Switching Router 162 MEG: Maintenance Entity Group 164 MEP: Maintenance Entity Group End Point 166 MIP: Maintenance Entity Group Intermediate Point 168 MPLS-OAM: MPLS Operations, Administration and Maintenance 170 MPLS-TP: MPLS Transport Profile 172 MPLS-TP LSP: Uni-directional or Bidirectional Label Switch Path 173 representing a circuit 175 MS-PW: Multi-Segment PseudoWire 177 NMS: Network Management System 179 PW: Pseudo Wire 181 RDI: Remote Defect Indication. 183 SPME: Sub-Path Maintenance Entity 184 TTL: Time To Live 186 TLV: Type Length Value 188 VCCV: Virtual Circuit Connectivity Verification 190 3. MPLS CC, proactive CV and RDI Mechanism using BFD 192 This document proposes distinct encapsulations and code points for 193 ACh encapsulated BFD depending on whether the mode of operation is CC 194 or CV: 196 o CC mode: defines a new code point in the Associated Channel Header 197 (ACH) described in RFC 5586[2].In this mode Continuity Check and 198 RDI functionalities are supported. 200 o CV mode: defines a new code point in the Associated Channel Header 201 (ACH) described in RFC 5586[2]. The ACH with "MPLS Proactive CV" 202 code point indicates that the message is an MPLS BFD proactive CV 203 and CC message and CC, CV and RDI functionalities are supported. 205 RDI: is communicated via the BFD diagnostic field in BFD CC and CV 206 messages. It is not a distinct PDU. A sink MEP will encode a 207 diagnostic code of "1- Control detection time expired" when the 208 interval times detect multipler have been exceeded, and with "3 - 209 neighbor signaled session down" as a consequence of the sink MEP 210 receiving AIS with LDI set. A sink MEP that has started sending diag 211 code 3 will NOT change it to 1 when the detection timer expires. 213 In accordance with RFC 5586[2], when these packets are encapsulated 214 in an IP header, the fields in the IP header are set as defined in 215 RFC 5884[8]. Further existing ACh code points and mechanisms for BFD 216 VCCV are specified in RFC5885[7]. These MAY be applied to 217 Pseudowires by configuration. Also by configuration, the BFD PW-ACH- 218 encapsulated for PW fault detection only encapsulation can be applied 219 to bi-directional LSPs by employing the GAL to indicate the presence 220 of the ACh. 222 A further artifact of IP encapsulation is that CV mis-connectivity 223 defect detection can be performed by inferring MEP_ID on the basis of 224 the combination of the source IP address and "my discriminator" 225 fields. 227 3.1. ACH code points for CC and proactive CV 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |0 0 0 1|Version| Flags |0xHH BFD CC/CV Code Point | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 1: ACH Indication of MPLS-TP Connectivity Verification 237 The first nibble (0001b) indicates the ACH. 239 The version and the flags are set to 0 as specified in [2]. 241 The code point is either 243 - BFD CC code point = 0xHH. [HH to be assigned by IANA from the PW 244 Associated Channel Type registry.] or, 246 - BFD proactive CV code point = 0xHH. [HH to be assigned by IANA from 247 the PW Associated Channel Type registry.] 249 Both CC and CV modes apply to PWs, MPLS LSPs (including SPMEs), and 250 Sections. 252 CC and CV operation can be simultaneously employed on an ME within a 253 single BFD session. The expected usage is that normal operation is to 254 send CC BFD PDUs with every nth BFD PDU augmented with a source MEP- 255 ID and identified as requiring additional processing by the different 256 ACh channel type. When CC and CV are interleaved, the minimum 257 insertion interval for CV PDUs is one per second. 259 3.2. MPLS BFD CC Message format 261 The format of an MPLS CC Message is shown below. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |0 0 0 1|Version| Flags | 0xHH BFD CC Code point | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 ~ BFD Control Packet ~ 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: MPLS CC Message 274 3.3. MPLS BFD proactive CV Message format 276 The format of an MPLS CV Message is shown below. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |0 0 0 1|Version| Flags | 0xHH BFD CV Code Point | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 ~ BFD Control Packet ~ 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 ~ Unique MEP-ID of source of the BFD packet ~ 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 3: MPLS CV Message 294 As shown in Figure 3, BFD Control packet as defined in [4] is 295 transmitted as MPLS labeled packets along with the ACH. Appended to 296 the BFD control packet is a MEP Source ID TLV. 298 A MEP Source ID TLV is encoded as a 2 octet field that specifies a 299 Type, followed by a 2 octet Length Field, followed by a variable 300 length Value field. 302 The length in the BFD control packet is as per [4]. There are 3 303 Source MEP TLVs (corresponding to the MEP-IDs defined in Error! 304 Reference source not found. [type fields to be assigned by IANA]. The 305 type fields are: 307 X1 - ICC encoded MEP-ID 309 X2 - LSP MEP-ID 311 X3 - PW MEP-ID 313 When GAL label is used, the TTL field of the GAL MUST be set to at 314 least 1, and the GAL will be the end of stack label (S=1). 316 A node MUST NOT change the value in the MEP Source ID TLV. 318 When digest based authentication is used, the Source ID TLV MUST NOT 319 be included in the digest 321 3.3.1. ICC-based MEP-ID 323 As defined in [9], the ICC-based MEP_ID consists of the MEG_ID, a 324 string of up to 13 characters (A-Z and 0-9), followed by the MEP 325 Index, an unsigned 16 bit integer that MUST be unique within the 326 context of the MEG_ID. 328 3.3.2. LSP MEP-ID 330 As defined in [9], the MPLS_TP LSP MEP-ID consists of the Node 331 Identifier, a thirty two bit identifier that MUST be unique within 332 the context of an operator's network, followed by the Tunnel_Num, an 333 unsigned sixteen bit integer that MUST be unique within the context 334 of the Node Identifier, and the LSP_NUM, an unsigned sixteen bit 335 integer that MUST be unique with the context of the Tunnel Num. 337 3.3.3. PW Endpoint MEP-ID 339 As defined in [9], the PW Endpoint MEP-ID consists of the Node 340 Identifier, a thirty two bit identifier that MUST be unique within 341 the context of an operator's network, followed by the AC_ID, a thirty 342 two bit identifier that MUST be unique within the context of the Node 343 Identifier. 345 In situations where global uniqueness is required, the Node 346 Identifier is preceded by the Global ID, a thirty two bit identifier 347 that contains the two-octet (right hand justified and preceded by 348 sixteen bits of zero) or four-octet value of the operator's 349 Autonomous System Number (ASN). 351 3.4. BFD Session in MPLS-TP terminology 353 A BFD session corresponds to a CC or a proactive CV OAM instance in 354 MPLS-TP terminology. 356 A BFD session is enabled when the CC or proactive CV functionality is 357 enabled on a configured Maintenance Entity (ME).. 359 On a Sink MEP, a BFD session can be in DOWN, INIT or UP state as 360 detailed in [4]. 362 When on a ME the CC or proactive CV functionality is disabled, the 363 BFD session transitions to the ADMIN DOWN State and the BFD session 364 ends. 366 A new BFD session is initiated when the operator enables or re- 367 enables the CC or CV functionality on the same ME. 369 3.5. BFD Profile for MPLS-TP 371 BFD MUST operate in asynchronous mode. In this mode, the BFD Control 372 packets are periodically sent at configurable time rate. This rate is 373 typically a fixed value for the lifetime of the session. In the rare 374 circumstance where an operator has a reason to change session 375 parameters, the session MUST be moved to the ADMIN DOWN state. 376 Poll/final discipline can only used for VCCV and UDP/IP encapsulated 377 BFD. 379 This document specifies bi-directional BFD for p2p transport LSPs, 380 hence the M bit MUST be clear. 382 There are two modes of operation for bi-directional LSPs. One in 383 which the session state of both directions of the LSP is coordinated 384 and one constructed from BFD sessions in such a way that the two 385 directions operate independently. A single bi-directional BFD session 386 is used for coordinated operation. Two independent BFD sessions are 387 used for independent operation. 389 Coordinated operation is as described in [4]. Independent operation 390 requires clarification of two aspects of [4]. Independent operation 391 is characterized by the setting of MinRxInterval to zero by the MEP 392 that is typically the session originator (referred to as the source 393 MEP), and there will be a session originator at either end of the bi- 394 directional LSP. Each source MEP will have a corresponding sink MEP 395 that has been configured to a Tx interval of zero. 397 The base spec is unclear on aspects of how a MEP with a BFD transmit 398 rate set to zero behaves. One interpretation is that no periodic 399 messages on the reverse component of the bi-directional LSP originate 400 with that MEP, it will only originate messages on a state change. 402 The first clarification is that when a state change occurs a MEP set 403 to a transmit rate of zero sends BFD control messages with a one 404 second period on the reverse component until such time that the state 405 change is confirmed by the session peer. At this point the MEP set to 406 a transmit rate of zero can resume quiescent behavior. This adds 407 robustness to all state transitions in the RxInterval=0 case. 409 The second is that the originating MEP (the one with a non-zero 410 TxInterval) will ignore a DOWN state received from a zero interval 411 peer. This means that the zero interval peer will continue to send 412 DOWN state messages that include the RDI diagnostic code as the state 413 change is never confirmed. This adds robustness to the exchange of 414 RDI indication on a uni-directional failure (for both session types 415 DOWN with a diagnostic of either control detection period expired or 416 neighbor signaled session down offering RDI functionality). 418 A further extension to the base specification is that there are 419 additional OAM protocol exchanges that act as inputs to the BFD state 420 machine; these are the Link Down Indication [5] and the Lock 421 Instruct/Lock Report transactions; Lock Report interaction being 422 optional. 424 3.5.1. Session initiation 426 In all scenarios a BFD session starts with both ends in the DOWN 427 state. DOWN state messages exchanged include the desired Tx and Rx 428 rates for the session. If a node cannot support the Min Tx rate 429 desired by a peer MEP it does not transition from down to the INIT 430 state and sends a diagnostic code of configuration error (to be 431 assigned by IANA) indicating that the requested Tx rate cannot be 432 supported. 434 Otherwise once a transition from DOWN to INIT has occurred, the 435 session progresses as per [4]. In both the DOWN and INIT states 436 messages are transmitted at a rate of one per second and the defect 437 detection interval is fixed at 3.5 seconds. On transition to the UP 438 state, message periodicity changes to the negotiated and/or 439 configured rate and the detect interval switches to detect multiplier 440 times the session peer's Tx Rate. 442 3.5.2. Defect entry criteria 444 There are further defect criteria beyond those that are defined in 445 [4] to consider given the possibility of mis-connectivity and mis- 446 configuration defects. The result is the criteria for a LSP direction 447 to transition from the defect free state to a defect state is a 448 superset of that in the BFD base specification [4]. 449 The following conditions cause a MEP to enter the defect state for CC 450 or CV: 451 1. BFD session times out (Loss of Continuity defect). 452 2. Receipt of a link down indication. 453 3. Receipt of an unexpected M bit (Session Mis-configuration 454 defect). 456 And the following will cause the MEP to enter the defect state for CV 457 operation 458 1. BFD control packets are received with an unexpected 459 encapsulation (mis-connectivity defect), these include: 460 - a PW receiving a packet with a GAL 461 - receiving an IP encoded CC or CV packet on a LSP configured 462 to use GAL/GaCH, or vice versa 463 (note there are other possibilities that can also alias as an 464 OAM packet) 465 2. Receipt of an unexpected globally unique Source MEP identifier 466 (Mis-connectivity defect). 467 3. Receipt of an unexpected session discriminator in the your 468 discriminator field (mis-connectivity defect). 469 4. Receipt of an expected session discriminator with an unexpected 470 label (mis-connectivity defect). 471 5. IF BFD authentication is used, receipt of a message with 472 incorrect authentication information (password, MD5 digest, or 473 SHA1 hash). 475 The effective defect hierarchy (order of checking) is 477 1. Receiving nothing. 479 2. Receiving link down indication. 481 3. Receiving from an incorrect source (determined by whatever 482 means). 484 4. Receiving from a correct source (as near as can be determined), 485 but with incorrect session information). 487 5. Receiving control packets in all discernable ways correct. 489 3.5.3. Defect entry consequent action 491 Upon defect entry a sink MEP will assert signal fail into any client 492 (sub-)layers. It will also communicate session DOWN to its session 493 peer. 495 The blocking of traffic as consequent action MUST be driven only by a 496 defect's consequent action as specified in draft-ietf-mpls-tp-oam- 497 framework [11] section 5.1.1.2. 498 When the defect is mis-branching, the LSP termination will silently 499 discard all non-oam traffic received. 501 3.5.4. Defect exit criteria 503 3.5.4.1. Exit from a Loss of continuity defect 505 For a coordinated session, exit from a loss of connectivity defect is 506 as described in figure 4 which updates [4]. 508 For an independent session, exit from a loss of connectivity defect 509 occurs upon receipt of a well formed control packet from the peer MEP 510 as described in figures 5 and 6. 512 3.5.4.2. Exit from a session mis-configuration defect 514 Exit from a misconfiguration defect occurs when two consecutive CC or 515 CV frames have been received with the expected M bit setting. 517 3.5.4.3. Exit from a mis-connectivity defect 519 Exit from a mis-connectivity defect state occurs when no CV messages 520 have been received with an incorrect source MEP-ID for a period of 521 3.5 seconds. 523 3.5.5. State machines 525 The following state machines update [4]. They have been modified to 526 include AIS with LDI set and LKI as specified in [5] as inputs to the 527 state machine and to clarify the behavior for independent mode. LKR 528 is an optional input. 530 The coordinated session state machine has been augmented to indicate 531 AIS with LDI set and optionally LKR as inputs to the state machine. 532 For a session that is in the UP state, receipt of AIS with LDI set or 533 optionally LKR will transition the session into the DOWN state. 535 +--+ 536 | | UP, ADMIN DOWN, TIMER, AIS-LDI, LKR 537 | V 538 DOWN +------+ INIT 539 +------------| |------------+ 540 | | DOWN | | 541 | +-------->| |<--------+ | 542 | | +------+ | | 543 | | | | 544 | | ADMIN DOWN,| | 545 | |ADMIN DOWN, DOWN,| | 546 | |TIMER TIMER,| | 547 V |AIS-LDI,LKR AIS-LDI,LKR | V 548 +------+ +------+ 549 +----| | | |----+ 550 DOWN| | INIT |--------------------->| UP | |INIT, UP 551 +--->| | INIT, UP | |<---+ 552 +------+ +------+ 554 Figure 4: State machine for coordinated session operation 556 For independent mode, there are two state machines. One for the 557 source MEP (who requested MinRxInterval=0) and the sink MEP (who 558 agreed to MinRxInterval=0). 560 The source MEP will not transition out of the UP state once 561 initialized except in the case of a forced ADMIN DOWN. Hence AIS-with 562 LDI set and optionally LKR do not enter into the state machine 563 transition from the UP state, but do enter into the INIT and DOWN 564 states. 566 +--+ 567 | | UP, ADMIN DOWN, TIMER 568 | V 569 DOWN +------+ INIT 570 +------------| |------------+ 571 | | DOWN | | 572 | +-------->| |<--------+ | 573 | | +------+ | | 574 | | | | 575 | |ADMIN DOWN ADMIN DOWN | | 576 | |TIMER, | | 577 | |AIS-LDI, | | 578 V |LKR | V 579 +------+ +------+ 580 +----| | | |----+ 581 DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN, 582 +--->| | INIT, UP | |<---+ AIS-LDI, LKR 583 +------+ +------+ 585 Figure 5: State machine for source MEP for independent session 586 operation 588 The sink MEP state machine (for which the transmit interval has been 589 set to zero) is modified to: 591 1) Permit direct transition from DOWN to UP once the session has been 592 initialized. With the exception of via the ADMIN DOWN state, the 593 source MEP will never transition from the UP state, hence in normal 594 unidirectional fault scenarios will never transition to the INIT 595 state. 597 +--+ 598 | | ADMIN DOWN, TIMER, AIS-LDI, LKR 599 | V 600 DOWN +------+ INIT, UP 601 +------------| |------------+ 602 | | DOWN | | 603 | +-------->| |<--------+ | 604 | | +------+ | | 605 | | | | 606 | | ADMIN DOWN,| | 607 | |ADMIN DOWN, TIMER, | | 608 | |TIMER, DOWN, | | 609 | |AIS-LDI, AIS-LDI, | V 610 V |LKR LKR | | 611 +------+ +------+ 612 +----| | | |----+ 613 DOWN| | INIT |--------------------->| UP | |INIT, UP 614 +--->| | INIT, UP | |<---+ 615 +------+ +------+ 617 Figure 6: State machine for the sink MEP for independent session 618 operation 620 3.5.6. Configuration of MPLS-TP BFD sessions 622 Configuration of MPLS-TP BFD session paramters and coordination of 623 same between the source and sink MEPs is out of scope of this memo. 625 3.5.7. Discriminator values 627 In the BFD control packet the discriminator values have either local 628 to the sink MEP or no significance (when not known). 630 My Discriminator field MUST be set to a nonzero value (it can be a 631 fixed value), the transmitted your discriminator value MUST reflect 632 back the received value of My discriminator field or be set to 0 if 633 that value is not known. 635 Per RFC5884 Section 7 [8], a node MUST NOT change the value of the 636 "my discriminator" field for an established BFD session. 638 4. Acknowledgments 640 Nitin Bahadur, Rahul Aggarwal, Dave Ward, Tom Nadeau, Nurit 641 Sprecher and Yaacov Weingarten also contributed to this 642 document. 644 5. IANA Considerations 646 This draft requires the allocation of two channel types from the 647 the IANA "PW Associated Channel Type" registry in RFC4446 [6]. 649 Xx MPLS-TP CC message 651 Xx+1 MPLS-TP CV message 653 This draft requires the creations of a source MEP-ID TLV 654 registry with initial values of: 656 Xx - ICC encoded MEP-ID 658 Xx+1 - LSP MEP-ID 660 Xx+2 - PW MEP-ID 662 The source MEP-ID TLV will require standards action registration 663 procedures for additional values. 665 This memo requests a code point from the registry for BFD 666 diagnostic codes [4]: 668 Xx - configuration error 670 6. Security Considerations 672 Base BFD foresees an optional authentication section (see [4] 673 section 6.7); that can be applied to this application. 675 7. References 677 7.1. Normative References 679 [1] Bradner, S., "Key words for use in RFCs to Indicate 680 Requirement Levels", BCP 14, RFC 2119, March 1997. 682 [2] Bocci, M. et al., " MPLS Generic Associated Channel ", RFC 683 5586 , June 2009 685 [3] Vigoureux, M., Betts, M. and D. Ward, "Requirements for 686 Operations Administration and Maintenance in MPLS 687 Transport Networks", RFC5860, May 2010 689 [4] Katz, D. and D. Ward, "Bidirectional Forwarding 690 Detection", RFC 5880, June 2010 692 [5] Swallow, G. et al., "MPLS Fault Management OAM", draft- 693 ietf-mpls-tp-fault-03 (work in progress), October 2010 695 [6] Martini, L., " IANA Allocations for Pseudowire Edge to 696 Edge Emulation (PWE3)", RFC 4446, April 2006 698 [7] Nadeau, T. et al. "Bidirectional Forwarding Detection 699 (BFD) for the Pseudowire Virtual Circuit Connectivity 700 Verification (VCCV) ", IETF RFC 5885, June 2010 702 [8] Aggarwal, R. et.al., "Bidirectional Forwarding Detection 703 (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, 704 June 2010 706 [9] Bocci, M. and G. Swallow, "MPLS-TP Identifiers", draft- 707 ietf-mpls-tp-identifiers-03 (work in progress), October 708 2010 710 7.2. Informative References 712 [10] Bocci, M., et al., "A Framework for MPLS in Transport 713 Networks", RFC5921, July 2010 715 [11] Allan, D., and Busi, I. "MPLS-TP OAM Framework", draft- 716 ietf-mpls-tp-oam-framework-10 (work in progress), December 717 2010 719 Authors' Addresses 721 Dave Allan 722 Ericsson 723 Email: david.i.allan@ericsson.com 725 John Drake 726 Juniper 727 Email: jdrake@juniper.net 729 George Swallow 730 Cisco Systems, Inc. 731 Email: swallow@cisco.com 733 Annamaria Fulignoli 734 Ericsson 735 Email: annamaria.fulignoli@ericsson.com 737 Sami Boutros 738 Cisco Systems, Inc. 739 Email: sboutros@cisco.com 741 Martin Vigoureux 742 Alcatel-Lucent 743 Email: martin.vigoureux@alcatel-lucent.com 745 Siva Sivabalan 746 Cisco Systems, Inc. 747 Email: msiva@cisco.com 749 David Ward 750 Juniper 751 Email: dward@juniper.net