idnits 2.17.1 draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a BFD session transits from one state to another, the traffic MUST not be affected. The blocking of traffic as consequent action MUST be driven only by a defect's consequent action as specified in the consequent action section 5.3. -- The document date (July 7, 2009) is 5406 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '13' is defined on line 1172, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-01 == Outdated reference: A later version (-07) exists of draft-sprecher-mpls-tp-oam-analysis-04 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-00 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-04 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-09 == Outdated reference: A later version (-02) exists of draft-bryant-mpls-tp-ach-tlv-00 -- No information found for draft-eitd-pwe3-oam-msg-map - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Fulignoli (Ed.) 3 Internet Draft Ericsson 4 Intended status: Informational 5 S. Boutros (Ed.) 6 Cisco Systems, Inc 8 M.Vigoureux (Ed.) 9 Alcatel-Lucent 11 Expires: January 2010 July 7, 2009 13 MPLS-TP BFD for Proactive CC-CV and RDI 14 draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance 19 with the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- 29 Drafts as reference material or to cite them other than as "work 30 in progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Statement 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. This document is subject 42 to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 43 Documents in effect on the date of publication of this document 44 (http://trustee.ietf.org/license-info). Please review these 45 documents carefully, as they describe your rights and 46 restrictions with respect to this document. 48 Abstract 50 Several documents on BFD based OAM for MPLS-TP has been put 51 forward and the dependencies between those drafts are not yet 52 fully sorted out; this document is one of these drafts. It is 53 published in now to make ideas, motivations and approaches 54 available. However we expect the final BFD based solution for 55 MPLS-TP will be a cooperation of the parties between the 56 existing drafts and that the BFD based OAM solution for MPLS-TP 57 will merge into an agreed set of drafts approved by the MEAD 58 team. 60 This document specifies the BFD extension and behaviour to meet 61 the requirements for MPLS-TP proactive Continuity Check and 62 Connectivity Verification functionality and the RDI 63 functionality as defined in [3]. 65 Table of Contents 67 1. Introduction...................................................3 68 1.1. Terminology..................................................4 69 2. Trail Termination Source Identifier (TTSI) TLV Object..........4 70 2.1. Unique ME Identifier.........................................6 71 2.1.1. LSP ME ID IPv4 Source/Destination Address Format...........7 72 2.1.2. LSP ME ID IPv6 Source/Destination Address Format...........8 73 2.1.3. Type FEC128PWv4 Format.....................................9 74 2.1.4. Type FEC128PWv6 Format.....................................9 75 2.1.5. ICC-based Format...........................................9 76 3. Two different ACH encapsulation of BFD tool...................11 77 3.1. Current BFD with only CC functionality......................11 78 3.2. New tool based on current BFD...............................12 79 4. Backward compatibility........................................13 80 5. BFD behavior specification for MPLS-TP OAM proactive CC&CV....13 81 5.1. BFD State Machine...........................................14 82 5.2. Defect conditions...........................................18 83 5.2.1. Loss of Continuity defect(dLOC)...........................18 84 5.2.2. Mis-connectivity defect (dUNME)...........................18 85 5.2.3. Unexpected MEP ID defect (dUNM)...........................18 86 5.2.4. Unexpected Period Defect (dUNP)...........................18 87 5.2.5. RDI Defect (dRDI).........................................19 88 5.3. Consequent action...........................................20 89 5.4. Administrative Down State...................................20 90 5.5. Timer Negotiation...........................................21 91 5.6. Demultiplexing and the Discriminator Fields.................22 92 6. Remote Defect Indication......................................22 93 7. BFD Control Packets field.....................................23 94 8. Interoperability with current BFD.............................27 95 9. Point to Multipoint transport paths...........................27 96 10. Acknowledgments..............................................28 97 11. Contributors.................................................28 98 12. IANA Considerations..........................................28 99 13. Security Considerations......................................28 100 14. References...................................................28 101 14.1. Normative References.......................................28 102 14.2. Informative References.....................................30 104 1. Introduction 106 Several documents on BFD based OAM for MPLS-TP has been put 107 forward and the dependencies between those drafts are not yet 108 fully sorted out; this document is one of these drafts. It is 109 published in now to make ideas, motivations and approaches 110 available. 112 However we expect the final BFD based solution for MPLS-TP will 113 be a cooperation of the parties between the existing drafts and 114 that the BFD based OAM solution for MPLS-TP will merge into an 115 agreed set of drafts approved by the MEAD team. 117 This document specifies the BFD extension and behaviour to meet 118 the requirements for MPLS-TP proactive Continuity Check and 119 Connectivity Verification functionality and the RDI 120 functionality as defined in [3]. 122 As recommended in [4], the BFD tool needs to be extended for the 123 CV functionality by the addition of a unique identifier in order 124 to meet the requirements. 126 As described in [5], the Proactive Continuity Check (CC) and 127 Continuity Verification (CV) function are used together to 128 detect loss of continuity (LOC), unintended connectivity between 129 two MEs (e.g. mismerging or misconnection) as well as unintended 130 connectivity within the ME with an unexpected MEP. It MUST 131 operate both in bidirectional and unidirectional p2p and 132 unidirectional p2mp connection. 134 The mechanism MUST foresee the configuration of the transmit 135 frequency. 137 The mechanism MUST be the same for LSP, (MS-)PW and Section as 138 well as for LSP Tandem Connection and PW Tandem Connection. 140 1.1. Terminology 142 LME LSP Maintenance Entity 144 LTCME LSP Tandem Connection Maintenance Entity 146 ME Maintenance Entity 148 MEP Maintenance End Point 150 MIP Maintenance Intermediate Point 152 PME PW Maintenance Entity 154 PTCME PW Tandem Connection Maintenance Entity 156 SME Section Maintenance Entity 158 TLV Type Length Value 160 Conventions used in this document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 163 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described 165 in RFC-2119 [1]. 167 2. Trail Termination Source Identifier (TTSI) TLV Object 169 The MPLS Generic Associated Channel specification (see[2] 170 section 3) describes the ACH TLV structure that can be used to 171 provide additional context information to the G-ACh packet. 173 In this section the TLV Objects for providing the MEP Identifier 174 information and the ME Identifier information as required by[5] 175 are described. 177 [Editor's note - Some ACH TLV objects defined in this section 178 can be moved in future versions of [10] and referenced by future 179 versions of this draft] 181 Note: in order to simply implementations (e.g. planning 182 processing resources), especially when BFD implementation is 183 hardware-assisted, it would be desirable to define the maximum 184 possible length for the all ACH TLV objects. 186 The TTSI TLV Object in figure below consists of the MEP-ID 187 followed by the Unique ME identifier TLV. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | TTSIAchTlvType = TBD | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | MEP ID value |Reserved ( fixed to all ZEROs) ! 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 ~ Unique ME ID TLV ~ 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Length 203 2 octets field; it specifies the number of octets which follows 204 the Length field. 206 MEP ID value 208 13-bit integer value field, identifying the transmitting MEP 209 within the ME. The three MSBs of the first octet are not used 210 and set to ZERO. 212 Unique ME ID 214 This is the ME Identifier TLV Object as described in section 215 2.1. 217 2.1. Unique ME Identifier 219 The globally unique ME Identifier ACH TLV objects have the 220 following structure : 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | ME ID Type | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 ~ ME ID Value ~ 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 ME ID Type 234 2 octet field; it identifies the format of the ME Identifier; 236 Length 238 2 octets field; it identifies the length in octets of the ME ID 239 Section that follows the length field. 241 ME ID payload 243 value of the ME identifier; its semantic depends on the format. 245 The ME Identifier Type transmitted and expected MUST be the same 246 at both MEPs. For statically provisioned connections, the ME 247 Identifier transmitted and expected is statically configured at 248 both MEPs. For dynamically established connections, the ME 249 Identifier transmitted and expected is signaled via the control 250 plane. The extension of ME identifier signaling is outside the 251 scope of this document. 253 Some possible ME Identifier formats are reported in the 254 following sections. 256 2.1.1. LSP ME ID IPv4 Source/Destination Address Format 258 This ME ID format MAY be used to identify an LME (as defined in 259 [5]) where IPv4 addresses are used to identify the LERs 260 terminating the LSP. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | ME ID Type | Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | IPv4 source address | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | IPv4 destination address | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Tunnel Index | TunnelInstance Index | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ME ID Type 276 2 octet field; it identifies the specific format, value = TBD; 278 Length 280 2 octets field; set to 12 (octets); 282 IPv4 source address 284 4 octets field; set to the IPv4 address of the LSP source 285 port/node; 287 IPv4 destination address 289 4 octets field; set to the IPv4 address of the LSP destination 290 port/node; 292 TunnelIndex 294 2 octets field as defined in RFC 3812 295 TunnelInstance Index 297 2 octets field as defined in RFC 3812 299 2.1.2. LSP ME ID IPv6 Source/Destination Address Format 301 This ME ID format MAY be used to identify an LME (as defined in 302 [5]) where IPv6 addresses are used to identify the LERs 303 terminating the LSP. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | ME ID Type | Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | IPv6 source address | 311 ~ (16 bytes) ~ 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | IPv6 destination address | 315 ~ (16 bytes) ~ 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Tunnel Index | TunnelInstance Index | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 ME ID Type 323 2 octet field; it identifies the specific format, value = TBD; 325 Length 327 2 octets field; set to 36 (octets); 329 IPv6 source address 331 4 octets field; set to the IPv6 address of the LSP source 332 port/node; 334 IPv6 destination address 335 4 octets field; set to the IPv6 address of the LSP destination 336 port/node; 338 TunnelIndex 340 2 octets field as defined in RFC 3812 342 TunnelInstance Index 344 2 octets field as defined in RFC 3812 346 2.1.3. Type FEC128PWv4 Format 348 This TLV is defined in [10]. It contains a PW ID that terminates 349 on a PE identified by an IPv4 address. 351 This ME ID format MAY be used to identify a PME (as defined in 352 [5]) where IPv4 addresses are used to identify the T-PEs 353 terminating the PW and FEC128 is used to identify the PW. 355 2.1.4. Type FEC128PWv6 Format 357 This TLV is defined in [10]. It contains a PW ID that terminates 358 on a PE identified by an IPv6 address. 360 This ME ID format MAY be used to identify a PME (as defined in 361 [5]) where IPv6 addresses are used to identify the T-PEs 362 terminating the PW and FEC128 is used to identify the PW. 364 Editor's note: implementation impacts of FEC129PWv4 and 365 FEC129PWv6 ( as defined in [10])when used as ME Identifier in a 366 cc-cv proactive tool needs further study (see note in section 2 367 regarding length of ME ID). 369 2.1.5. ICC-based Format 371 This ME ID format MAY be used to identify SME, LME, LTCME, PME 372 and PTCME(as defined in [5]) independently on LER/T-PE 373 addressing schemes as well as of the FECs used to identify the 374 PW. 376 Editor's note: for these reasons it is suggested to have this 377 format as a MUST and the other format as optional in the MPLS-TP 378 environment. 380 EndofEditornote 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | ME ID Type | Length | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | | 388 + + 389 | MEG ID | 390 + (13 bytes) + 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 ME ID Type 398 2 octet field; it identifies the specific format, value = TBD; 400 Length 402 2 octets field; set to 16; 404 MEG ID value 406 13-octet field. Refer to Annex A of ITU-T Recommendation Y.1731 407 for the format used for the MEG ID field with ICC-based format. 409 Editor's note: to decide if insert all ICC-based MEG ID format 410 (as for Figure A-2 of Y.1731 or only the MEG-ID value as 411 reported now in above figure EndofEditornote 413 3. Two different ACH encapsulation of BFD tool 415 Among the solutions analyzed in [11], the one based on two 416 separate tools, running with two different ACH encapsulations 417 (i.e. two different ACH channel types): 419 o the current BFD with only CC functionality; 421 o a new tool based on current BFD that meet all the OAM MPLS-TP 422 requirement. 424 is proposed in this document as the solution to be standardized. 426 As all analyzed solutions reported in [11], even this one 427 implies extension of CV types, foreseen by [6] and yet extended 428 by[7], in order to include the MPLS-TP OAM mechanism too for PW 429 Fault Detection only. This is due to the fact that VCCV also 430 includes mechanisms for negotiating the control channel and 431 connectivity verification (i.e. OAM functions) between PEs. 433 This version of the draft is focused on fault detection on the 434 transport path. 436 3.1. Current BFD with only CC functionality 438 The current BFD, with only CC functionality, is encapsulated in 439 the G-ACH using as Channel type code point the 0x0007 value as 440 described in [7]. This mechanism can be even extended to SME, 441 LME, LTCME and PTCME. 443 Figure below shows G-ACH encapsulation of current BFD as in [7] 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 + + 452 | BFD control packet | 453 + + 454 : ... : 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 3.2. New tool based on current BFD 460 The new tool is obtained introducing TTSI TLV , described in 461 section 2. between the ACH and the current BFD (defined in [8]) 462 as detailed below. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | ACH TLV Header | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 + TTSI TLV 473 : ... : 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 ~ BFD Control packet ~ 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 The first four bytes represent the G-ACH ([2]). 481 - first nibble: set to 0001b to indicate a channel associated 482 with a PW, a LSP or a Section; 484 - Version and Reserved fields are set to 0, as specified in[2] 485 [2]; 487 - G-ACH Channel Type field with a new TBD code point meaning 488 "MPLS-TP CC-CV proactive" indicating that the message is an 489 MPLS-TP OAM CC-CV proactive message. The value MUST be assigned 491 The G-ACH is followed by the ACH TLV Header as defined in 492 Section 3 of [2] and by one and only one TTSI ACH TLV object 493 carrying the MEP Identifier and the Unique ME Identifier 494 Information. ( see section 2. ) 495 The IP-based addressing ACH TLV objects ( see [10]) that allow 496 the usage if this tool also within an IP/MPLS environment can be 497 even present. In any case the TTSI ACH TLV object MUST be always 498 carried in the last ACH TLV object ( i.e just before the BFD 499 packet). 501 The BFD control packet is the base BFD as described [8]. 503 The benefit of this solution is to maintain the base behavior 504 and protocol version of BFD as defined in[8] and in [9]; 505 however, it's necessary to define some rules that specify the 506 BFD profile for MPLS-TP application as detailed in the next 507 sections. 509 The proposed solutions needs even some considerations on the 510 optional Authentication Section how described in section 10. 512 From now on this solution is referred as extended BFD. 514 4. Backward compatibility 516 For backward compatibility, it is still possible to run the 517 current BFD that supports only CC functionality on some 518 transport paths and the new tool that supports CC and CV 519 functionality on other transport paths. In any case, only one 520 tool for OAM instance at time, configurable by operator, can 521 run. 523 A MEP that is configured to support CC and CV functionality, as 524 required by MPLS-TP, MUST be capable to receive existing BFD 525 packets (encapsulated with GAL/G-ACH or PW-ACH) that supports 526 only CC functionality and MUST consider them as an unexpected 527 packet, i.e. detect a misconnection defect. 529 5. BFD behavior specification for MPLS-TP OAM proactive CC&CV 531 In this section some rules that specify the MPLS-TP application 532 of the extended BFD is detailed. These rules apply even for the 533 base BFD, limited to the CC functionality only, when an MPLS-TP 534 node interoperates with MPLS legacy nodes or when only the CC 535 functionality is required . 537 The BFD control packet is the base BFD as described in [8]. 539 The extended BFD MUST operate both in bidirectional and 540 unidirectional p2p and unidirectional p2mp connection. 542 This version of the draft is focused on unidirectional and 543 bidirectional p2p connection of the MPLS-TP CC-CV proactive 544 tool. 546 Unidirectional p2mp connections are even reported but it 547 requires further analysis. 549 In this document the BFD operating mode is always Asynchronous; 550 in this mode the systems send CC/CV BFD packets, carrying a 551 unique ME identifier and sender MEP identifier, at regular 552 configurable timing rate. If a LOC defect or a mis-connectivity 553 defect or a period mis-configuration defect occurs, the BFD 554 session is declared down. For proactive CC-CV functionality 555 description please refers to [5]. 557 5.1. BFD State Machine 559 The BFD State Machine is described in [8] for bidirectional p2p 560 connection and in [9] for p2mp unidirectional connection. 562 The main goals in defining the state machine for MPLS-TP 563 extended BFD are: 565 1. to interoperate with the state machines defined in [8] and in 566 [9]; 568 2. to satisfy the CC-CV proactive monitoring functionality and even 569 the RDI functionality as specified in the MPLS-TP OAM framework 570 [5]. 572 The diagram in Figure 1 provides an overview of the state 573 machine for MEP configured on p2p bidirectional transport path, 574 as defined in [8]. 576 +--+ 577 | | UP, ADMIN DOWN, Defects, 578 | V 579 DOWN +------+ INIT 580 +------------| |------------+ 581 | | DOWN | | 582 | +-------->| |<--------+ | 583 | | +------+ | | 584 | | | | 585 | | ADMIN DOWN,| | 586 | |ADMIN DOWN, DOWN,| | 587 | |Defects Defects | | 588 V | | V 589 +------+ +------+ 590 +----| | | |----+ 591 DOWN| | INIT |--------------------->| UP | |INIT, UP 592 +--->| | INIT, UP | |<---+ 593 +------+ +------+ 595 Figure 1: State Machine for p2p bidirectional connection 597 The diagram in Figure 2 provides an overview of the state 598 machine for MEP Sink of unidirectional p2p unidirectional 599 transport path based on the state machine defined in [9]; 600 (DOWN), ADMIN DOWN, 601 +------+ Defects +------+ 602 +----| |<---------------------| |----+ 603 (DOWN)| | DOWN | | UP | |UP 604 ADMIN DOWN,+--->| |--------------------->| |<---+ 605 Defects +------+ UP +------+ 607 Figure 2: State Machine for p2p unidirectional connection 609 State transitions on MEP Source on unidirectional p2p path are 610 administratively driven. 612 In both diagram, each arc represents the state of the remote 613 system (as received in the State field in the BFD Control 614 packet) or indicates the expiration of the Detection Timer, here 615 extended to general defect raising and clearing conditions as 616 reported in Table 1. 618 As reported in [8], another state (AdminDown) exists so that a 619 session can be administratively put down indefinitely. In the 620 above diagram Transitions involving AdminDown state are deleted 621 for clarity; further considerations are reported in section 5.4. 623 Editor's note: 625 . It is suggested to introduce the following new bfd.SessionType 626 in [9]: 628 o MPLS-TP bidirectional p2p: Transport Profile of the 629 Classic point-to-point BFD . 631 o MPLS-TP unidirectional Sink 633 o MPLS-TP unidirectional Source 635 . In [9] DOWN State in received BFD is even reported. It is 636 suggested to remove it from [9] as well as from Figure 3 as 637 State transitions on MEP Source on unidirectional p2p and p2mp 638 path are administratively driven . 640 . If in Figure 1 we assume that 642 o a MPLS-TP node transits from DOWN to UP State even when 643 receiving UP State and not only INIT State and that 645 o a Source MEP of a unidirectional path only transmits BFD 646 packets in UP state or AdminDown State, the diagram in 647 Figure 2 becomes a ''sub-branch'' of state machine reported 648 in Figure 1 650 EndofEditor's note 652 . The ''Defects Raise'' and ''Defects Clear'' Event in Figure 1 and 653 Figure 2 occurs when: 655 o Defect Raise Event = dLOC or dUNME or dUNM or dUNP; 657 o Defect Clear Event = (not dLOC)and(not dUNME)and(not 658 dUNM)and (not dUNP); 660 o See section 5.2. for defect conditions description. 662 . When on a configured bidirectional MEP the proactive CC-CV 663 monitoring is enabled, the MEP sends the CC/CV BFD packet with 664 frequency of the configured transmission period and it also 665 expects to receive the CC/CV BFD packets from its peer MEP with 666 the same transmission period (see [5]). 668 . In a unidirectional (point-to-point or point-to-multipoint) 669 transport path , where the proactive CC-CV monitoring is 670 enabled, only the Source MEP is enabled to generate CC/CV BFD 671 packets with frequency of the configured transmission period and 672 always with UP State information . This MEP does not expect to 673 receive any CC/CV BFD packets from its peer MEP in the ME 675 . a MEP Sink, configured on a unidirectional transport path where 676 the proactive CC-CV monitoring is enabled, expects to receive 677 the CC/CV BFD packets from its peer MEP at the configured 678 period; the defects detection procedure is the same as the 679 bidirectional MEP; no CC/CV BFD packets are sent on the ME. 681 It is worth noticing that CC-CV proactive monitoring can be 682 enabled/disabled by an operator on a configured ME and this MUST be 683 not traffic affecting. Please refers to [5] for hitless 684 enable/disable CC-CV proactive monitoring procedure. 686 When a BFD session transits from one state to another, the traffic 687 MUST not be affected. The blocking of traffic as consequent action 688 MUST be driven only by a defect's consequent action as specified in 689 the consequent action section 5.3. 691 When the CC-CV proactive monitoring is disabled on a ME no CC/CV 692 BFD packets are sent on the ME neither defects are monitored; 693 however, the MEP must terminate all OAM packets it receives and in 694 case of CC-CV proactive packets it must recognize a mis- 695 connectivity even if the CC-CV proactive monitoring is disabled on 696 the MEP. 698 5.2. Defect conditions 700 Defect triggered at the MPLS-TP layer by the CC-CV proactive 701 tool are reported in this section. 703 5.2.1. Loss of Continuity defect(dLOC) 705 If no CC/CV BFD packets from a peer MEP are received within the 706 interval equal to K times (see Table 1) the receiving MEP's 707 configured CC-CV transmission period, loss of continuity with 708 peer MEP is detected. 710 5.2.2. Mis-connectivity defect (dUNME) 712 If an extended BFD with a ME ID different than the configured 713 expected one is received , mis-connectivity defect is detected. 715 5.2.3. Unexpected MEP ID defect (dUNM) 717 If a CC-CV BFD packet with expected ME ID but with an incorrect 718 MEP ID, including the receiving MEP's own MEP ID, is received, 719 Unexpected MEP is detected. 721 5.2.4. Unexpected Period Defect (dUNP) 723 If a CC-CV BFD packet is received with a correct ME ID, a 724 correct MEP ID, but with a period field value different than the 725 receiving MEP's own CC-CV transmission period, Unexpected Period 726 is detected. 728 5.2.5. RDI Defect (dRDI) 730 The Remote Defect Indicator defect monitors the presence of an 731 RDI maintenance signal. A MEP detects RDI defect when it 732 receives a CC/CV BFD packet with the RDI field set. 734 The following Table summarizes the defect raising and clearing 735 conditions 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |Defect |Raising Condition |Clearing Condition | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |dLOC |#Rx BFD==0 (K*CV_Period) |#Rx BFD >= N (K*CV_Period) | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 |dUNME |Unexpected ME Identifier |#UnexpMEId==0 (K*CV_Period) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 |dUNM |Unexpected MEP Id |#UnexpMEPId==0 (K*CV_Period) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |dUNP |Unexpected Period |#UnexpPeriod==0 (K*CV_Period)| 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 |dRDI | Rx RDI == 1 | Rx RDI ==0 | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Table 1: Table of Raising Clearing Defect Conditions 752 In Table 1, N and K are protocol constants to be defined; the 753 CV_Period corresponds to the configured transmission period; 755 K value is stored in bfd.DetectMult variable while the CV_Period 756 is stored bfd.DesiredMinTxInterval variable and carried in the 757 relative BFD packet fields. 759 5.3. Consequent action 761 . If a MEP detects an unexpected ME Identifier, or an unexpected 762 MEP, it MUST block (BLK) all the traffic (including also the 763 user data packets) that it receives from the misconnected 764 transport path. 766 . If a MEP detects LOC defect and the CC-CV monitoring is enabled 767 it MUST block (BLK) all the traffic (including also the user 768 data packets) that it receives from the misconnected transport 769 path. This consequent action is configurable (see [5]) 771 . If a MEP detects an unexpected ME Identifier, or an unexpected 772 MEP it MUST declare a Transport Path Fail (TSF). 774 . If a MEP detects LOC defect and the CC-CV monitoring is enabled 775 it MUST declare a Transport Path Fail (TSF). 777 . If a MEP declare a Transport Path Fail it MUST insert an RDI 778 information towards its peer MEP in a bidirectional connection 780 Consequent actions are identified by abbreviation prefixed with 781 an 'a': aXXX, e.g. aTSF. The consequent actions detailed above 782 can be so summarized : 784 aBLK <-- (dUNME or dUNM) or (dLOC and CC- 785 CV_Monitoring_Enabled and LOC_cons_action_Enabled) 787 aTSF <-- (dLOC and CC-CV_Monitoring_Enabled)or dUNME or dUNM 788 or Server_SF 790 aRDI <-- aTSF 792 5.4. Administrative Down State 794 As reported in[8]: ''a session MAY be kept administratively down 795 by entering the AdminDown state and sending an explanatory 796 diagnostic code in the Diagnostic field. AdminDown state means 797 that the session is being held administratively down. This 798 causes the remote system to enter Down state, and remain there 799 until the local system exits AdminDown state. AdminDown state 800 has no semantic implications for the availability of the 801 forwarding path.'' 802 Please not that the AdminDown state semantic MUST be not 803 confused with the LOCK functionality as reported in [3]. In this 804 document the AdminDown state semantic is equivalent to disabling 805 on a MEP the CC-CV proactive monitoring; in this case the source 806 MEP SHOULD send BFD Control packets in AdminDown state for a 807 period equal to(bfd.DesiredMinTxInterval * bfd.DetectMult) in 808 order to ensure that the remote system is aware of the state 809 change. 811 An MPLS-TP MEP receiving a BFD packet with AdminDown State MUST 812 transit to the DOWN State and report the event to the operator. 813 Editor's note: 815 In this case the operator should disable the functionality even 816 on the other node. Should the node still report the LOC defect ? 817 If Yes the AdminDown State received can be a simple 818 report/warning to the operator. 820 End editor's note 822 5.5. Timer Negotiation 824 The negotiation of time value foreseen by the base BFD (see [8]) 825 MUST be disabled on the MPLS-TP extended BFD. The timer 826 negotiation should be even disabled on an MPLS-TP node that runs 827 only the CC functionality as well as on a node that 828 interoperates with current BFD. It's up to the operator 829 configure the BFD transmission period on the MPLS-TP node in a 830 way that is suitable for the MPLS legacy node. 832 The configured BFD packet transmission period MUST be stored 833 into the bfd.DesiredMinTxInterval variable and carried into the 834 ''Desired Min TX Interval field'' of the transmitted BFD 836 For a bidirectional point-to-point transport path the same 837 bfd.DesiredMinTxInterval value MUST be stored even in 838 bfd.RequiredMinRxInterval; source MEP of unidirectional session 839 MUST set the bfd.RequiredMinRxInterval to 0. 841 The bfd.DesiredMinRxInterval value is carried into the ''Required 842 Min RX Interval field '' of the transmitted BFD. 844 If BFD packets are received with the ''Desired Min TX Interval 845 field '' different from than expected and stored in the local 846 bfd.DesiredMinTxInterval variable the Unexpected Period defect 847 is detected. 849 Please note that this behavior doesn't preclude the base BFD 850 session running on a MPLS legacy node to adapt to the BFD timers 851 transmitted by an MPLS-TP node. 853 The configured transmission period MUST be one of the following 854 values, both for the extended BFD and current BFD running on a 855 MPLS-TP node: 857 . 3.33 ms: Default transmission period for protection switching 858 application (transmission rate of 300 packets/second); 860 . 10 ms: (Transmission rate is 100 packets/second); 862 . 100 ms: Default transmission period for performance monitoring 863 application (transmission rate of 10 packets/second); 865 . 1 s: Default transmission period for fault management 866 application (transmission rate of 1 packets/second). 868 5.6. Demultiplexing and the Discriminator Fields 870 The context of MPLS-TP OAM packets is based on MPLS label and G- 871 ACH, eliminating in the BFD the need to exchange Discriminator 872 values. 874 An MPLS-TP node that interoperates with a base BFD can apply the 875 same discriminator field semantic as described in [8] or: 877 . It MUST set the My discriminator field to a nonzero value (it 878 can be a fixed value); 880 . It MUST reflect back the received value of My discriminator 881 field into the transmitted Your discriminator field, or set it 882 to zero if that value is unknown. 884 6. Remote Defect Indication 886 The Remote Defect Indication (RDI) is an indicator that is 887 transmitted by a MEP to communicate to its peer MEP that a 888 signal fail condition exists. RDI is only used for 889 bidirectional connections and is associated with proactive CC & 890 CV packet generation.[5] 891 Editor's note: in last version of MPLS-TP OAM requirement 892 ([3])the RDI functionality is now even for unidirectional 893 connection if a return path exist. However this implies a 894 further analysis 896 End of Editor's note 898 The Diagnostic (Diag) field of base BFD ([8]) can be used for 899 this functionality. However, there isn't a total correspondence 900 among the values foreseen by [8] and the defect conditions 901 detected by the proactive CC-CV tool that require the RDI 902 function. A solution could be that any defect that requires the 903 RDI information being sent to the peer MEP is encoded in the 904 Diagnostic (Diag) field with the value 1 (corresponding to the 905 ''Control Detection Time Expired'' in [8]). The value 0 indicates 906 RDI condition has been cleared. 908 This applies for the extended BFD and for the base BFD when a 909 MPLS-TP node runs only the CC functionality 911 7. BFD Control Packets field 913 As defined in [8], the mandatory Section of a BFD Control packet 914 has the following format: 916 0 1 2 3 917 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 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | My Discriminator | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Your Discriminator | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Desired Min TX Interval | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Required Min RX Interval | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Required Min Echo RX Interval | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 The contents of transmitted and expected BFD Control packets on 932 a MPLS-TP node for the mechanism proposed in this document are 933 detailed below both for extended BFD as well as current BFD: 935 Version 937 Set to the current version number (1). If version number is not 938 correct the packet is discarded. 940 Diagnostic (Diag) 942 The following value are requested to be supported among the 943 value reported in [8]: 945 0 -- No Diagnostic 947 1 -- Remote Defects Indication 949 3 -- Neighbor Signaled Session Down 951 7 -- Administratively Down 953 Different values are ignored in receipt. 955 State (Sta) 957 The current BFD session state as seen by the transmitting 958 system. Values are: 960 0 -- AdminDown 962 1 -- Down 964 2 -- Init 966 3 -- Up 968 Poll (P) 970 If set, the transmitting system is requesting verification of 971 connectivity, or of a parameter change, and is expecting a 972 packet with the Final (F) bit in reply. If clear, the 973 transmitting system is not requesting verification. 975 Final (F) 977 If set, the transmitting system is responding to a received BFD 978 Control packet that had the Poll (P) bit set. If clear, the 979 transmitting system is not responding to a Poll. 981 Control Plane Independent (C) 983 Is not required to be supported on a MPLS-TP node. Set to 1 on 984 transmit and ignored in receipt. 986 Authentication Present (A) 988 Set to 1 if authentication is in use on this session 989 (bfd.AuthType is nonzero), or 0 if not. 991 Demand (D) 993 Set to 0 in asynchronous mode. 995 Multipoint (M) 997 Set to 1 if bfd.SessionType is MultipointHead (Source MEP of a 998 point to multipoint connection). Otherwise it is set to 0. 1000 Detect Mult 1002 Detection time multiplier. The configured transmit interval, 1003 multiplied by this value, provides the Detection Time for the 1004 transmitting system in Asynchronous mode. This is the K protocol 1005 constants as defined in Table 1. 1007 Length 1009 Set to the appropriate length, in bytes, of the only BFD Control 1010 packet, based on the fixed header length (24) plus any 1011 Authentication Section. 1013 My Discriminator 1015 A unique, nonzero discriminator value generated by the 1016 transmitting system. See section 5.6. 1018 Your Discriminator 1020 The discriminator received from the corresponding remote system. 1021 This field reflects back the received value of My Discriminator, 1022 or is zero if that value is unknown. See section 5.6. 1024 Desired Min TX Interval 1026 This is the configured BFD packet transmission period, in 1027 microseconds and stored into the bfd.DesiredMinTxInterval 1028 variable. See section 5.5. 1030 Required Min RX Interval 1032 This is the configured BFD packet period, in microseconds and 1033 stored into the bfd.RequiredMinRxInterval variable. Source MEP 1034 of unidirectional session MUST set it to 0 See section 5.5. 1036 Required Min Echo RX Interval 1038 Is not required to be supported on a MPLS-TP node; set to 0. 1040 An optional Authentication Section MAY be present. For details 1041 see section 10. 1043 8. Interoperability with current BFD 1045 There's no interoperability issue among a MPLS-TP node running 1046 the current BFD, with the rules defined in previous sections, 1047 and legacy MPLS node at PW layer network level as the use of the 1048 CC Type 1 was previously defined and limited to PWs. (See [7]) 1050 Instead, any Network Partitioning scenario with LSP Stitching 1051 present interoperability issues as LSP Ping is designated to 1052 bootstrap the BFD session in an MPLS environment and the session 1053 BFD messages for MPLS are transmitted using a IP/UDP 1054 encapsulation (see [12] and [4]); the IWF requires further 1055 analysis. 1057 This section will be completed in the next version of the draft. 1059 9. Point to Multipoint transport paths 1061 Solution described in section 3.2. is also valid for p2mp 1062 connections. The extended multipoint BFD packets are explicitly 1063 marked as such, via the setting of the M bit (see [9]). 1065 The diagrams reported Figure 2 provides also an overview of the 1066 state machine for MEP Sink configured on each tail of a p2mp 1067 path. 1069 MEP Source, head of unidirectional p2mp, will never receive 1070 packets and have no Detection Timer, and as such all state 1071 transitions are administratively driven. 1073 The MEP Source sends the extended multipoint BFD packet in the 1074 multicast tree at a configured transmission period. 1076 A unidirectional point-to-multipoint connection containing n 1077 end-points contains (n-1) MEs, each one independently monitored 1078 by MEP Sink configured on each tail as described in section 5. 1080 Editor's note: 1082 . It is suggested to introduce the following new bfd.SessionType 1083 in [9]: 1085 oMPLS-TP MultipointHead: Transport Profile of 1086 MultipointHead 1088 oMPLS-TP MultipointTail: Transport Profile of 1089 MultipointTail 1091 EndofEditor's note 1093 This section requires further analysis. 1095 10. Acknowledgments 1097 1099 This document was prepared using 2-Word-v2.0.template.dot. 1101 11. Contributors 1103 12. IANA Considerations 1105 1107 13. Security Considerations 1109 Base BFD [8] foresees an optional authentication section; that 1110 can be extended even to the tool proposed in this document. 1112 Authentication methods that require checksum calculation on the 1113 outgoing packet must extend the checksum even on the ME 1114 Identifier Section. This is possible but seems uncorrelated with 1115 the solution proposed in this document: it could be better to 1116 use the simple password authentication method. 1118 It is also worth noticing that the interactions between 1119 authentication and connectivity verification need further 1120 analysis. 1122 14. References 1124 14.1. Normative References 1126 [1] Bradner, S., "Key words for use in RFCs to Indicate 1127 Requirement Levels", BCP 14, RFC 2119, March 1997. 1129 [2] Bocci, et al., " MPLS Generic Associated Channel ", RFC 1130 5586 , June 2009 1132 [3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 1133 in MPLS Transport Networks", draft-ietf-mpls-tp-oam- 1134 requirements-01 (work in progress), March 2009 1136 [4] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, 1137 Y., " MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam- 1138 analysis-04 (work in progress), May 2009 1140 [5] Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and 1141 Overview", draft-ietf-mpls-tp-oam-framework-00(work in 1142 progress), March 2009 1144 [6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1145 Connectivity Verification (VCCV): A Control Channel for 1146 Pseudowires", RFC 5085, December 2007 1148 [7] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1149 Detection (BFD) for the Pseudowire Virtual Circuit 1150 Connectivity Verification (VCCV)",ID draft-ietf-pwe3-vccv- 1151 bfd-04.txt, Work in Progress, May 2009 1153 [8] Katz, D. and D. Ward, "Bidirectional Forwarding 1154 Detection", draft-ietf-bfd-base-09.txt (work in progress), 1155 February 2009. 1157 [9] Katz, D. and D. Ward, "BFD for Multipoint Networks", 1158 ID draft-katz-ward-bfd-multipoint-02.txt, February 2009 1160 [10] S. Boutros, et. al., "Definition of ACH TLV Structure", 1161 draft-bryant-mpls-tp-ach-tlv-00.txt, Work in 1162 Progress, January 2009. 1164 [11] A. Fulignoli, et. al.,''MPLS-TP Proactive Continuity and 1165 Connectivity Verification'', draft-fhbs-mpls-tp-cv- 1166 proactive-00.txt (work in progress), February 2009 1168 [12] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1169 "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07 (work 1170 in progress), June 2008. 1172 [13] Martini, L.and M.Morrow, ''Pseudo Wire (PW) OAM Message 1173 Mapping'', draft-eitd-pwe3-oam-msg-map-10 (work in 1174 progress), April 2009 1176 14.2. Informative References 1178 Authors' Addresses 1180 Annamaria Fulignoli (Editor) 1181 Ericsson 1182 Email: annamaria.fulignoli@ericsson.com 1184 Sami Boutros 1185 Cisco Systems, Inc. 1186 Email: sboutros@cisco.com 1188 Martin Vigoureux 1189 Alcatel-Lucent 1190 Email: martin.vigoureux@alcatel-lucent.com