idnits 2.17.1 draft-fhbs-mpls-tp-cv-proactive-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 -- The document date (February 9, 2009) is 5552 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-gach-gal-01 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-07) exists of draft-sprecher-mpls-tp-oam-analysis-02 == Outdated reference: A later version (-02) exists of draft-busi-mpls-tp-oam-framework-00 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-02 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-08 == Outdated reference: A later version (-02) exists of draft-katz-ward-bfd-multipoint-01 == Outdated reference: A later version (-02) exists of draft-bryant-mpls-tp-ach-tlv-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group A. Fulignoli (Ed) 2 Internet Draft Ericsson 3 Intended status: Informational H. van Helvoort (Ed) 4 Huawei 5 I. Busi (Ed) 6 Alcatel-Lucent 7 N.Sprecher (Ed) 8 Nokia Siemens Networks 10 Expires: August 2009 February 9, 2009 12 MPLS-TP Proactive Continuity and Connectivity Verification 13 draft-fhbs-mpls-tp-cv-proactive-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 The aim of this draft is to define an MPLS-TP OAM mechanism to meet 50 the requirements for proactive Continuity Check and Connectivity 51 Verification functionality as defined in [3]. 53 Note: this version of the draft is focused on analyzing possible 54 solutions and evaluating their pros&cons as well as issues. In the 55 next version of the draft the solution to be standardized will be 56 proposed using the analysis done in this version to motivate the 57 selection. 59 Table of Contents 61 1. Introduction.................................................3 62 1.1. Terminology.............................................3 63 2. Unique ME Identifier.........................................4 64 2.1. LSP ME ID IPv4 Source/Destination Address Format........5 65 2.2. LSP ME ID IPv6 Source/Destination Address Format........6 66 2.3. Type FEC128PWv4 Format..................................7 67 2.4. Type FEC128PWv6 Format..................................7 68 2.5. ICC-based Format........................................7 69 3. Possible Solution............................................8 70 3.1. Backward compatibility..................................9 71 4. Definition of BFDv2.........................................10 72 4.1. New semantic for Discriminator fields..................10 73 4.2. New ME ID field........................................12 74 5. Two different ACH encapsulation of OAM tool.................13 75 5.1. Current BFD with only CC functionality.................13 76 5.2. ACH encapsulation of the new tool......................13 77 5.2.1. New tool based on current BFD.....................14 78 5.2.2. New tool based on the extended BFD................15 79 5.2.3. New tool like Y.1731 CCM..........................15 80 6. Remote Defect Indication....................................18 81 7. Point to Multipoint transport paths.........................18 82 8. Conclusion..................................................18 83 9. Security Considerations.....................................19 84 10. IANA Considerations........................................19 85 11. Acknowledgments............................................19 86 12. References.................................................19 87 12.1. Normative References..................................19 88 12.2. Informative References................................20 90 1. Introduction 92 The aim of this draft is to define an MPLS-TP OAM mechanism to meet 93 the requirements for proactive Continuity Check and Connectivity 94 Verification functionality required in [3]. 96 Note: this version of the draft is focused on analyzing possible 97 solutions and evaluating their pros&cons as well as issues. In the 98 next version of the draft the solution to be standardized will be 99 proposed using the analysis done in this version to motivate the 100 selection. 102 As recommended in [4], the BFD tool needs to be extended for the CV 103 functionality by the addition of a unique identifier in order to meet 104 the requirements. This document further expands the analysis of 105 possible solutions. 107 As described in [5], the Proactive Continuity Check (CC) and 108 Continuity Verification (CV) function are used together to detect 109 loss of continuity (LOC), unintended connectivity between two MEs 110 (e.g. mismerging or misconnection) as well as unintended connectivity 111 within the ME with an unexpected MEP. It MUST operate both in 112 bidirectional p2p and in unidirectional p2mp connection. 114 The mechanism MUST foresee the configuration of the transmit 115 frequency. 117 The mechanism MUST be the same for LSP, (MS-)PW and Section. 119 1.1. Terminology 121 LME LSP Maintenance Entity 123 ME Maintenance Entity 125 MEP Maintenance End Point 127 MIP Maintenance Intermediate Point 129 PME PW Maintenance Entity 131 SME Section Maintenance Entity 132 TCME Tandem Connection Maintenance Entity 134 TPME Tandem PW Maintenance Entity 136 TLV Type Length Value 138 Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC-2119 [1]. 144 2. Unique ME Identifier 146 The globally unique ME Identifier can use some of the ACH TLV objects 147 defined in Section 3 of [10]: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | ME ID Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 ~ ME ID Value ~ 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 ME ID Type 161 2 octet field; it identifies the format of the ME Identifier; 163 Length 165 2 octets field; it identifies the length in octets of the ME ID 166 Section that follows the length field. 168 ME ID payload 170 value of the ME identifier; its semantic depends on the format. 172 [Editor's note - Some ACH TLV objects defined in this section can be 173 moved in future versions of [10] and referenced by future versions of 174 this draft] 176 Note: in order to simply implementations (e.g. planning processing 177 resources), especially when BFD implementation is hardware-assisted, 178 it would be desirable to define the maximum possible length for the 179 CV TLV. 181 The ME Identifier Type transmitted and expected MUST be the same at 182 both MEPs. For statically provisioned connections, the ME Identifier 183 transmitted and expected is statically configured at both MEPs. For 184 dynamically established connections, the ME Identifier transmitted 185 and expected is signaled via the control plane. The extension of ME 186 identifier signaling is outside the scope of this document. 188 Some possible ME Identifier formats are reported in the following 189 sections. 191 2.1. LSP ME ID IPv4 Source/Destination Address Format 193 This ME ID format MAY be used to identify an LME (as defined in [5]) 194 where IPv4 addresses are used to identify the LERs terminating the 195 LSP. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | ME ID Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | IPv4 source address | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | IPv4 destination address | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | LSP ID | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ME ID Type 211 2 octet field; it identifies the specific format, value = TBD; 213 Length 214 2 octets field; set to 12 (octets); 216 IPv4 source address 218 4 octets field; set to the IPv4 address of the LSP source port/node; 220 IPv4 destination address 222 4 octets field; set to the IPv4 address of the LSP destination 223 port/node; 225 LSP ID 227 4 octets field; set to the LSP identifier. 229 2.2. LSP ME ID IPv6 Source/Destination Address Format 231 This ME ID format MAY be used to identify an LME (as defined in [5]) 232 where IPv6 addresses are used to identify the LERs terminating the 233 LSP. 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ME ID Type | Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | IPv6 source address | 241 ~ (16 bytes) ~ 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | IPv6 destination address | 245 ~ (16 bytes) ~ 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | LSP ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 ME ID Type 253 2 octet field; it identifies the specific format, value = TBD; 255 Length 256 2 octets field; set to 36 (octets); 258 IPv6 source address 260 4 octets field; set to the IPv6 address of the LSP source port/node; 262 IPv6 destination address 264 4 octets field; set to the IPv6 address of the LSP destination 265 port/node; 267 LSP ID 269 4 octets field; set to the LSP identifier. 271 2.3. Type FEC128PWv4 Format 273 This TLV is defined in [10]. It contains a PW ID that terminates on a 274 PE identified by an IPv4 address. 276 This ME ID format MAY be used to identify a PME (as defined in [5]) 277 where IPv4 addresses are used to identify the T-PEs terminating the 278 PW and FEC128 is used to identify the PW. 280 2.4. Type FEC128PWv6 Format 282 This TLV is defined in [10]. It contains a PW ID that terminates on a 283 PE identified by an IPv6 address. 285 This ME ID format MAY be used to identify a PME (as defined in [5]) 286 where IPv6 addresses are used to identify the T-PEs terminating the 287 PW and FEC128 is used to identify the PW. 289 Editor's note: implementation impacts of FEC129PWv4 and FEC129PWv6 ( 290 as defined in [10])when used as ME Identifier in a cc-cv proactive 291 tool needs further study (see note in section 2 regarding length of 292 ME ID). 294 2.5. ICC-based Format 296 This ME ID format MAY be used to identify SME, LME, LTCME, PME and 297 PTCME(as defined in [5]) independently on LER/T-PE addressing schemes 298 as well as of the FECs used to identify the PW. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | ME ID Type | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | MEP ID value | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 307 | MEG ID | 308 + (13 bytes) + 309 | | 310 + +-+-+-+-+-+-+-+-+ 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ME ID Type 316 2 octet field; it identifies the specific format, value = TBD; 318 Length 320 2 octets field; set to 15; 322 MEP ID value 324 13-bit integer value field, identifying the transmitting MEP within 325 the ME. The three MSBs of the first octet are not used and set to 326 ZERO. 328 MEG ID value 330 13-octet field. Refer to Annex A of ITU-T Recommendation Y.1731 for 331 the format used for the MEG ID field with ICC-based format. 333 3. Possible Solution 335 Several solutions have been analyzed: 337 1. Define a new BFD version (BFDv2) that extends the current BFD 338 (BFDv1) to support also CV functionality. The new BFD version can 339 be obtained by: 341 1. changing the semantic of MY discriminator and Your discriminator 342 fields ([8]); 344 2. adding a new ME ID field in the BFD packet for the CV 345 functionality to the existing session identifier; 347 2. two separate tools, running with two different ACH encapsulations 348 (i.e. two different ACH channel types): 350 o the current BFD with only CC functionality; 352 o a new tool that meet all the OAM MPLS-TP requirement. 354 The new tool can be: 356 1. based on current BFD; 358 2. an extension of the ACH encapsulation for the current BFD; 360 3. a new tool like Y.1731 CCM; 362 All analyzed solutions imply extension of CV types, foreseen by [6] 363 and yet extended by[7], in order to include the MPLS-TP OAM mechanism 364 too. This is due to the fact that VCCV also includes mechanisms for 365 negotiating the control channel and connectivity verification (i.e. 366 OAM functions) between PEs. 368 3.1. Backward compatibility 370 For backward compatibility, it is still possible to run the current 371 BFD that supports only CC functionality on some transport paths and 372 the new tool that supports CC and CV functionality on other transport 373 paths. In any case only one tool for OAM instance at time, 374 configurable by operator, can run. 376 A MEP that is configured to support CC and CV functionality, as 377 required by MPLS-TP, MUST be capable to receive existing BFD packets 378 (encapsulated with GAL/G-ACH or PW-ACH) that supports only CC 379 functionality and MUST consider them as an unexpected packet, i.e. 380 detect a misconnection defect. 382 The context of MPLS-TP OAM packets is based on MPLS label and G-ACH, 383 eliminating in the BFD the need to exchange Discriminator values. An 384 MPLS-TP node that desires to interoperate with a current BFD can 385 apply the same discriminator field semantic as described in [8] or: 387 o It MUST set the My discriminator field to a nonzero value (it can 388 be a fixed value); 390 o It MUST reflect back the received value of My discriminator field 391 into the transmitted Your discriminator field, or set it to zero 392 if that value is unknown. 394 4. Definition of BFDv2 396 Common to both solutions detailed in this section are the following 397 considerations: 399 o The Channel Type field of the G-ACH is the one proposed by [7] 400 i.e. 0x0007 indicating the raw BFD control packet; 402 o The version number of the protocol needs to be updated to protocol 403 version 2 respect to protocol version 1 defined in [8] 405 4.1. New semantic for Discriminator fields 407 As defined in [8], the mandatory Section of a BFD Control packet has 408 the following format: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | My Discriminator | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Your Discriminator | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Desired Min TX Interval | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Required Min RX Interval | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Required Min Echo RX Interval | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 A possible BFD extension can be obtained changing the semantic of the 427 two 32 bit fields, My Discriminator and Your Discriminator, to form a 428 one 64 bit field carrying the globally unique ME Identifier as shown 429 in figure below: 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 + ME ID + 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Desired Min TX Interval | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Required Min RX Interval | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Required Min Echo RX Interval | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 One of the disadvantages of this solution is on the too limited 448 number of octets available for the globally unique ME ID field: that 449 doesn't allow the possibility to have different format of ME 450 identifier. 452 4.2. New ME ID field 454 This solution adds the new field required for the CV functionality, 455 i.e. a globally unique ME Identifier section, after the mandatory 456 section of a BFD control packet and before the optional 457 Authentication section as the figure below shows: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | My Discriminator | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Your Discriminator | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Desired Min TX Interval | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Required Min RX Interval | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Required Min Echo RX Interval | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 + ME ID Section + 476 : ... : 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 + Optional Authentication Section + 480 : ... : 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 The advantages of this solution are that the behavior of the current 484 BFD protocol as defined in [8] is unchanged and on the variable 485 length of the ME ID Section. 487 5. Two different ACH encapsulation of OAM tool 489 5.1. Current BFD with only CC functionality 491 The current BFD, with only CC functionality, is encapsulated in the 492 G-ACH using as Channel type code point the 0x0007 value as described 493 in [7]. This mechanism can be even extended to Section OAM and LSP 494 OAM. 496 Figure below shows G-ACH encapsulation of current BFD as in [7] 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |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| 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 + + 505 | BFD control packet | 506 + + 507 : ... : 508 | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 5.2. ACH encapsulation of the new tool 513 In order to meet the MPLS-TP OAM requirement, a new tool has to be 514 introduced, encapsulated into the G-ACH with a new channel type code 515 point. Common to all solutions detailed below are the following G-ACH 516 format: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 - first nibble: set to 0001b to indicate a channel associated with a 525 PW, a LSP or a Section; 527 - Version and Reserved fields are set to 0, as specified in [2]; 528 - G-ACH Channel Type field with a new TBD code point meaning "MPLS-TP 529 CC-CV proactive" indicating that the message is an MPLS-TP OAM CC-CV 530 proactive message. The value MUST be assigned 532 The sections below describe the format of the different possible new 533 tool. 535 5.2.1. New tool based on current BFD 537 A new tool can be obtained introducing a globally unique ME 538 Identifier TLV between the ACH and the current BFD (defined in [8]) 539 as detailed below. 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | ACH TLV Header | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 + ME ID TLV 550 : ... : 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | 553 ~ BFD Control packet ~ 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 The first 4 bytes represent the G-ACH as described in section 5.2. 558 The G-ACH is followed by the ACH TLV Header as defined in Section 2.1 559 of [10] and by one ACH TLV object carrying the Unique ME Identifier 560 Section as described in section 2. 562 The BFD control packet is the base BFD as described [8]. 564 The benefit of this solution is to maintain the behavior and protocol 565 version of BFD as defined in[8]; however it needs some considerations 566 on the optional Authentication Section how described in section 9. 568 5.2.2. New tool based on the extended BFD 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | My Discriminator | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Your Discriminator | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Desired Min TX Interval | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Required Min RX Interval | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Required Min Echo RX Interval | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 + ME ID Section + 589 : ... : 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 + Optional Authentication Section + 593 : ... : 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 The solutions and considerations are the same of what described in 597 section 4.2. except the G-ACH Channel type code, rather than the 598 Version field, distinguishes between existing BFD (supporting CC) and 599 the new tools (supporting both CC&CV). 601 The Version field in this case is set to 0 (this is the first version 602 for this tool). 604 5.2.3. New tool like Y.1731 CCM 606 The Mandatory Section of the CC/CV packet has the following format: 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Vers | Res1 | Res2 |A|R| Res3 | Per | Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | 617 + ME ID Section + 618 : ... : 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 An optional Authentication Section may be present: 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Auth Type | Auth Len | Authentication Data... | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 This is inherited and described in [8]. 631 Version (Vers) 633 4 bit field, version number of the protocol; this document defines 634 protocol version 0; 636 Reserved (Res1) 638 4 bit field, reserved for future use; set to all ZEROes; 640 Reserved (Res2) 641 7 bit field; reserved for future use; set to all ZEROes; 643 Authentication Present (A) 645 1 bit field; if set, the Authentication Section is present and the 646 session is to be authenticated; 648 RDI (R) 650 1 bit field; it is set to 1 to indicate Remote Defect Indication 651 otherwise it is set to 0. 653 Reserved (Res3) 655 4 bit field reserved for future use; set to all ZEROes; 657 Period (Per) 659 3 bit field; it indicates the transmission period with the encoding 660 shown in the following table: 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 |0 0 0| Invalid value | Invalid value for CCM PDU | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |0 0 1| 3.33 ms | 300 frames per second | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 |0 1 0| 10 ms | 100 frames per second | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |0 1 1| 100 ms | 10 frames per second | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 |1 0 0| 1 s | 1 frame per second | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 |1 0 1| 10 s | 6 frames per minute | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 |1 1 0| 1 min | 1 frame per minute | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 |1 1 1| 10 min | 6 frame per hour | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Length 682 1 octet field; it is the total CC/CV packet length in octet, 683 excluded the G-ACH header; 685 ME ID Section 686 Variable length field containing the Unique Path Identifier as 687 detailed in section 2. 689 This solution has the advantage of an easier peer interworking with 690 the ETH OAM. 692 6. Remote Defect Indication 694 Remote Defect Indication (RDI) is used by a MEP to notify its peer 695 MEP that a defect is detected on a bi-directional connection between 696 them([4]). RDI is only used for bidirectional connections and is 697 associated with proactive CC & CV packet generation.[5] 699 The Diagnostic (Diag) field of the Current BFD ([8]) can be used for 700 this functionality. However, there isn't a total correspondence among 701 the values foreseen by [8] and the defect conditions detected by the 702 proactive CC-CV tool that require the RDI function. 704 A solution could be that any defect that requires the RDI information 705 being sent to the peer MEP is encoded in the Diagnostic (Diag) field 706 with the value 1 (corresponding to the ''Control Detection Time 707 Expired'' in [8]). The value 0 indicates RDI condition has been 708 cleared. 710 This section will be completed in the next version of the draft. 712 For the solution in section 5.2.3. , RDI is foreseen in the packet 713 format with a single bit. 715 7. Point to Multipoint transport paths 717 Solution described in section 5.2.3. is valid for both bidirectional 718 and unidirectional connection: in unidirectional connection only 719 source MEP is enabled only to generate CC/CV OAM packets and sink MEP 720 is enabled only to receive CC/CV OAM packets. 722 The BFD tool has a straightforward state machine for bidirectional 723 path. Anyway the behavior and state machine need to be modified for 724 the unidirectional connection; this is described in [9]. 726 This section will be completed in the next version of the draft. 728 8. Conclusion 730 CC and CV functionality are required to be used always together for 731 MPLS-TP OAM (see [3] and [5]). 733 For interoperability issue, a MPLS-TP node MAY support even the 734 current BFD tool; anyway only one tool, configurable by operator, for 735 OAM instance MUST run at time. 737 This section will be completed in the next version of the draft. 739 9. Security Considerations 741 Base BFD [8] foresees an optional authentication section; that can be 742 extended even to the tool proposed in this document. 744 Authentication methods that require checksum calculation on the 745 outgoing packet must extend the checksum even on the ME Identifier 746 Section. This is possible but seems uncorrelated with the solution 747 proposed in section 5.2.1. in this case it could be better to use the 748 simple password authentication method. 750 It is also worth noticing that the interactions between 751 authentication and connectivity verification need further analysis. 753 10. IANA Considerations 755 757 11. Acknowledgments 759 761 This document was prepared using 2-Word-v2.0.template.dot. 763 12. References 765 12.1. Normative References 767 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 768 Levels", BCP 14, RFC 2119, March 1997. 770 [2] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., 771 " MPLS Generic Associated Channel ", draft-ietf-mpls-tp-gach- 772 gal-01 (work in progress), January 2009 774 [3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 775 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 776 00 (work in progress), November 2008 778 [4] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., " 779 MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02 780 (work in progress), September 2008 782 [5] Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and 783 Overview", draft-busi-mpls-tp-oam-framework-00(work in 784 progress), October 2008 786 [6] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 787 Connectivity Verification (VCCV): A Control Channel for 788 Pseudowires", RFC 5085, December 2007 790 [7] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 791 Detection (BFD) for the Pseudowire Virtual Circuit 792 Connectivity Verification (VCCV)",ID draft-ietf-pwe3-vccv-bfd- 793 02.txt, February 2008. 795 [8] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", 796 draft-ietf-bfd-base-08 (work in progress), March 2008. 798 [9] Katz, D. and D. Ward, "BFD for Multipoint Networks", 799 ID draft-katz-ward-bfd-multipoint-01.txt, December 2007 801 [10] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- 802 bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. 804 12.2. Informative References 806 Authors' Addresses 808 Italo Busi (Editor) 809 Alcatel-Lucent 810 Email: italo.busi@alcatel-lucent.it 812 Annamaria Fulignoli (Editor) 813 Ericsson 814 Email: annamaria.fulignoli@ericsson.com 816 Huub van Helvoort (Editor) 817 Huawei Technologies 818 Email: hhelvoort@huawei.com 820 Nurit Sprecher 821 Nokia Siemens Networks 822 Email: nurit.sprecher@nsn.com