idnits 2.17.00 (12 Aug 2021) /tmp/idnits33684/draft-boutros-mpls-tp-cv-cc-00.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 6, 2009) is 4695 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: draft-ietf-mpls-tp-oam-requirements has been published as RFC 5860 == Outdated reference: draft-ietf-bfd-base has been published as RFC 5880 == Outdated reference: draft-ietf-bfd-generic has been published as RFC 5882 == Outdated reference: draft-ietf-pwe3-vccv-bfd has been published as RFC 5885 == Outdated reference: draft-ietf-mpls-tp-framework has been published as RFC 5921 == Outdated reference: A later version (-02) exists of draft-bryant-mpls-tp-ach-tlv-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sami Boutros (Ed.) 3 Internet Draft Siva Sivabalan (Ed.) 4 Intended status: Standards Track George Swallow (Ed.) 5 Expires: February 2010 7 Cisco Systems, Inc. 9 Martin Vigoureux (Ed.) 10 Alcatel-Lucent 12 A. Fulignoli (Ed.) 13 Ericsson 15 July 6, 2009 17 Connection Verification and Continuity Check for MPLS Transport 18 Profile Label Switched Path 19 draft-boutros-mpls-tp-cv-cc-00.txt 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on February 6, 2010. 44 Abstract 46 Connection Verification (CV) and Continuity Check (CC) are 47 important Operations, Administration, and Management (OAM)functions 48 of MPLS Transport Profile (MPLS-TP). This document specifies 49 methods for CV and CC for MPLS-TP Label Switched Path (LSP) using 50 Bidirectional Forwarding Detection (BFD). 52 Table of Contents 54 1. Introduction...................................................2 55 2. Terminology....................................................3 56 3. MPLS-TP Connection Verification and Continuity Check Mechanism.3 57 3.1. MPLS-TP CV/CC Message format..............................4 58 3.2. BFD Profile for MPLS-TP...................................5 59 4. Operation......................................................6 60 5. Security Considerations........................................7 61 6. IANA Considerations............................................7 62 7. References.....................................................7 63 7.1. Normative References......................................7 64 7.2. Informative References....................................7 65 Author's Addresses................................................8 66 Full Copyright Statement..........................................9 67 Intellectual Property Statement...................................9 69 1. Introduction 71 In traditional transport networks, circuits are provisioned on 72 multiple switches. Service Providers (SP) need OAM tools to detect 73 mis-connectivity and loss of continuity of transport circuits. MPLS- 74 TP LSPs [6] emulating traditional transport circuits need to provide 75 the same CC and CV capabilities as mentioned in [2]. This document 76 describes the use of BFD [3] for CV and CC of an MPLS-TP LSP between 77 2 Maintenance End Points (MEPs). The mechanism specified in this 78 document is restricted only to BFD asynchronous mode. The proposed 79 method uses BFD state machine defined in Section 6.2 of [3]. 81 Moreover, this document recommends the use of BFD for the Pseudowire 82 Virtual Circuit Connectivity Verification (VCCV)as defined in [5]. 84 Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC-2119 [1]. 90 2. Terminology 92 ACH: Associated Channel Header 94 BFD: Bidirectional Forwarding Detection 96 CV: Connection Verification 98 EOS: End of Stack 100 GAL: Generalized Alert Label 102 LSR: Label Switching Router 104 MEP: Maintenance End Point 106 MIP: Maintenance Intermediate Point 108 MPLS-OAM: MPLS Operations, Administration and Maintenance 110 MPLS-TP: MPLS Transport Profile 112 MPLS-TP LSP: Bidirectional Label Switch Path representing a circuit 114 MS-PW: Mult-Segment PseudoWire 116 NMS: Network Management System 118 PW: PseudoWire 120 RR: Record Route 122 TLV: Type Length Value 124 TTL: Time To Live 126 RDI: Remote defect indication. 128 3. MPLS-TP Connection Verification and Continuity Check Mechanism 130 The proposed mechanism is based on a new code point in the Generic 131 Associated Channel Header (G-ACH) described in [8]. Under MPLS label 132 stack of the MPLS-TP LSP, the ACH with "MPLS-TP Connection 133 Verification/Continuity Check (CV/CC)" code point indicates that the 134 message is an MPLS-TP CV/CC message. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |0 0 0 1|Version| Flags | 0xHH MPLS-TP CV/CC Code Point | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: ACH Indication of MPLS-TP Connection Verification 144 The first nibble (0001b) indicates the ACH. 146 The version and the reserved values are both set to 0 as specified in 147 [8]. 149 MPLS-TP CV/CC code point = 0xHH. [HH to be assigned by IANA from the 150 PW Associated Channel Type registry.] 152 3.1. MPLS-TP CV/CC Message format 154 The format of an MPLS-TP CV/CC Message format is shown below. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | LSP Label (EOS) | TC |S| TTL | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | GAL | TC |S| TTL | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | ACH | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 165 | | 166 ~ Destination and Source Node-IDs of the MPLS-TP LSP ~ 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 ~ BFD Control Packet ~ 171 | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 2: MPLS-TP CV/CC Message 175 As shown in Figure 2, BFD Control packet as defined in [3] is 176 transmitted as MPLS labeled packets along with GAL, G-ACH, and TLVs 177 carrying the Destination and Source Node-IDs of the MPLS-TP LSP as 178 defined in a new IETF draft to be published soon. 180 The TTL field of the GAL MUST be set to at least 1, and the GAL will 181 be the end of stack label. 183 The discriminator values in the BFD control packet will be set to the 184 LIH (Logical Interface Handle) at each side of the MPLS-TP LSP. 186 Combination of the Source/Destination Node-IDs and discriminator 187 value (from the BFD packet) represents MEP-ID, i.e., the combination 188 of the source node address and my discriminator is the Source MEP-ID, 189 and the combination of the destination node address and your 190 discriminator is the peer MEP-ID. Note that the format of Node ID is 191 defined in [7]. 193 In this mode of operation, the IP/UDP headers for the BFD control 194 packets are omitted from the BFD encapsulation. 196 Furthermore, BFD is used not only for fault detection but also for 197 mis-insertion and for Remote Defect Indication (RDI). Reception of a 198 BFD control packet having an unexpected source Node-ID, destination 199 Node-ID or discriminator(s) is considered a BFD mis-insertion fault. 201 Reception of BFD control packet with a diagnostic code of 1 (Control 202 Detection Time Expired) or 5 (Path down) is considered an RDI fault. 204 3.2. BFD Profile for MPLS-TP 206 BFD MUST run in asynchronous mode as described in [3]. 208 In all BFD control packets sent, both "Desired Min TX Interval" and 209 "Required Min RX Interval" MUST be set to the operator configured 210 values for BFD transmission period for the MPLS-TP LSP. If the 211 received BFD packets have different "Desired Min TX Interval field" 212 than the one used for the transmitted packets, the BFD session MUST 213 NOT come up by default, except if the behavior is overridden by an 214 operator using explicit configuration. 216 By default the transmission rates MUST be the same at both end of the 217 MPLS-TP LSP (both working and protecting). 219 The "my discriminator" field in the BFD control packets is set to the 220 MPLS-TP LSP's local LIH (Logical Interface Handle) and the "your 221 discriminator" field is initially set to zero. During BFD session 222 negotiation, the "my discriminator" field in the received BFD packets 223 MUST match the remote discriminator. 225 4. Operation 227 Single-hop BFD initialization procedures described in [4] are 228 followed. As mentioned before, only asynchronous mode is supported. 229 The operation of BFD over MPLS-TP LSP is symmetrical. Both endpoints 230 of the bidirectional MPLS-TP LSP MUST send BFD messages inband in the 231 MPLS-TP LSP using the defined code point. 233 Both MEPs at the end of an MPLS-TP LSP need to bootstrap the BFD 234 session and start sending BFD control packets encapsulated within 235 MPLS-TP CV/CC message described in this document. MPLS-TP LSP labels 236 at both ends of the MPLS-TP LSP will be used as the de-multiplexer 237 for the received BFD packets, and no discriminator values will be 238 used. 240 A single BFD session per MPLS-TP LSP will exist between the MEP's of 241 the MPLS-TP LSP. Both MEP's will be sending initial BFD Control 242 packets with a "Your Discriminator" field of zero, and BFD Control 243 packets received with a "Your Discriminator" field of zero are 244 associated to the BFD session bound to the MPLS-TP LSP. 246 Both "Desired Min TX Interval" and "Required Min RX Interval" MUST be 247 set to the configured BFD transmission period for the MPLS-TP LSP. 249 Assume an MPLS-TP LSP that spans across LSR-A, LSR-B and LSR-C. LSR-A 250 LSR-C act as the MEPs whereas LSR-B act as a MIP for the MPLS-TP LSP. 251 Furthermore, assume that on both LSR-A and LSR-C the operator 252 provision the BFD detection time multiplier as per [3]. 254 If LSR-A receives a BFD control message that has a destination node 255 identifier different from it's identifier, or has an unexpected 256 source node identifier, or non-zero your discriminator value or has a 257 my discriminator value different from what LSR-A is expecting, LSR-A 258 declares that the MPLS-TP LSP is down in its receive direction. In 259 this case, LSR-A signals LSR-C that the BFD session is down using the 260 State (Sta) with diagnostic code 5 (Path down). 262 If LSR-A stops receiving BFD control messages from LSR-C for a period 263 of detection time multiplier (calculation of Detection Time is 264 defined in[3]), LSR-A declares that the MPLS-TP LSP is down in its 265 receive direction, and signals this to the remote end via the State 266 (Sta) with Diagnostic code 1(Control Detection Time Expired). In 267 turn, LSR-C declares the MPLS-TP LSP is down in its transmit 268 direction setting the State to Down with Diagnostic code 3 (Neighbor 269 signaled session down) in its control messages to LSR-A. 271 5. Security Considerations 273 The security considerations for the authentication TLV need further 274 study. 276 6. IANA Considerations 278 To be added. 280 7. References 282 7.1. Normative References 284 [1] Bradner. S, "Key words for use in RFCs to Indicate Requirement 285 Levels", RFC 2119, March, 1997. 287 [2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 288 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 289 02 (work in progress), June 2009. 291 [3] Katz, D., and D. Ward, "Bidirectional Forwarding Detection", 292 draft-ietf-bfd-base-09 (work in progress), August 2009. 294 [4] Katz, D., and D. Ward, "Generic Application of BFD", draft- 295 ietf-bfd-generic-05 (work in progress), February 2009. 297 [5] T. Nadeau, et. Al, Bidirectional Forwarding Detection (BFD) for 298 the Pseudowire Virtual Circuit Connectivity Verification 299 (VCCV), draft-ietf-pwe3-vccv-bfd-05, June 2009. 301 7.2. Informative References 303 [6] M. Bocci, et. al., "A Framework for MPLS in Transport 304 Networks", draft-ietf-mpls-tp-framework-01.txt, Work in 305 Progress, June 2009. 307 [7] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- 308 bryant-mpls-tp-ach-tlv-01.txt, Work in Progress, May 2009. 310 [8] M. Bocci, et. al., "MPLS Generic Associated Channel", RFC 5586, 311 June, 2009. 313 Author's Addresses 315 Sami Boutros 316 Cisco Systems, Inc. 317 3750 Cisco Way 318 San Jose, California 95134 319 USA 320 Email: sboutros@cisco.com 322 Siva Sivabalan 323 Cisco Systems, Inc. 324 2000 Innovation Drive 325 Kanata, Ontario, K2K 3E8 326 Canada 327 Email: msiva@cisco.com 329 George Swallow 330 Cisco Systems, Inc. 331 300 Beaver Brook Road 332 Boxborough , MASSACHUSETTS 01719 333 United States 334 Email: swallow@cisco.com 336 David Ward 337 Cisco Systems, Inc. 338 3750 Cisco Way 339 San Jose, California 95134 340 USA 341 Email: wardd@cisco.com 343 Stewart Bryant 344 Cisco Systems, Inc. 345 250, Longwater, Green Park, 346 Reading RG2 6GB, UK 347 UK 348 Email: stbryant@cisco.com 350 Martin Vigoureux 351 Alcatel-Lucent 353 Email: martin.vigoureux@alcatel-lucent.com 355 Annamaria Fulignoli (Editor) 357 Ericsson 359 Email: annamaria.fulignoli@ericsson.com 361 Full Copyright Statement 363 Copyright (c) 2009 IETF Trust and the persons identified as the 364 document authors. All rights reserved. 366 This document is subject to BCP 78 and the IETF Trust's Legal 367 Provisions Relating to IETF Documents in effect on the date of 368 publication of this document (http://trustee.ietf.org/license-info). 369 Please review these documents carefully, as they describe your rights 370 and restrictions with respect to this document. 372 All IETF Documents and the information contained therein are provided 373 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 374 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 375 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 376 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 377 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 378 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 379 FOR A PARTICULAR PURPOSE. 381 Intellectual Property Statement 383 The IETF takes no position regarding the validity or scope of any 384 Intellectual Property Rights or other rights that might be claimed to 385 pertain to the implementation or use of the technology described in 386 this document or the extent to which any license under such rights 387 might or might not be available; nor does it represent that it has 388 made any independent effort to identify any such rights. 390 Copies of Intellectual Property disclosures made to the IETF 391 Secretariat and any assurances of licenses to be made available, or 392 the result of an attempt made to obtain a general license or 393 permission for the use of such proprietary rights by implementers or 394 users of this specification can be obtained from the IETF on-line IPR 395 repository at http://www.ietf.org/ipr. 397 The IETF invites any interested party to bring to its attention any 398 copyrights, patents or patent applications, or other proprietary 399 rights that may cover technology that may be required to implement 400 any standard or specification contained in an IETF Document. Please 401 address the information to the IETF at ietf-ipr@ietf.org. 403 The definitive version of an IETF Document is that published by, or 404 under the auspices of, the IETF. Versions of IETF Documents that are 405 published by third parties, including those that are translated into 406 other languages, should not be considered to be definitive versions 407 of IETF Documents. The definitive version of these Legal Provisions 408 is that published by, or under the auspices of, the IETF. Versions of 409 these Legal Provisions that are published by third parties, including 410 those that are translated into other languages, should not be 411 considered to be definitive versions of these Legal Provisions. 413 For the avoidance of doubt, each Contributor to the UETF Standards 414 Process licenses each Contribution that he or she makes as part of 415 the IETF Standards Process to the IETF Trust pursuant to the 416 provisions of RFC 5378. No language to the contrary, or terms, 417 conditions or rights that differ from or are inconsistent with the 418 rights and licenses granted under RFC 5378, shall have any effect and 419 shall be null and void, whether published or posted by such 420 Contributor, or included with or in such Contribution. 422 Acknowledgment 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.