idnits 2.17.1 draft-dunbar-so-mpls-detect-impair-mplsping-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 13, 2010) is 4976 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) == Missing Reference: 'MPLS-Ping' is mentioned on line 135, but not defined == Missing Reference: 'MPLS-Ping-Enhanced' is mentioned on line 150, but not defined == Unused Reference: 'ECN' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'MPLS-PING' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'BFD-MPLS' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'LSP-Ping-Enhanced' is defined on line 301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (ref. 'MPLS-PING') (Obsoleted by RFC 8029) -- Possible downref: Non-RFC (?) normative reference: ref. 'BFD-MPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-Ping-Enhanced' Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group L. Dunbar 2 Internet Draft Huawei 3 Intended status: Standard Track N. So 4 Expires: February 2011 Verizon 5 P. Niger, Y. Le Goff 6 France Telecom 7 August 13, 2010 9 Detecting MPLS Path Impairment using MPLS-Ping 11 draft-dunbar-so-mpls-detect-impair-mplsping-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on February 13, 2009. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the BSD License. 51 Abstract 53 The MPLS-Ping is for detecting data path failure. This draft suggests 54 an extension to MPLS-Ping so that transit LSR can indicate the 55 downstream link impairment condition to the source LSR. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 0. 63 Table of Contents 65 1. Motivation..........................................2 66 2. MPLS-Ping extension for path condition impairment indication..3 67 2.1. Downstream Link Condition sub-TLV...................4 68 2.2. Link Condition Request in Echo Request...............5 69 2.3. Receiving Echo Request with a Path Condition Request flag set 70 ..................................................6 71 3. Receiving Path Condition Impairment Notification...........6 72 4. Manageability Considerations...........................7 73 5. Security Considerations...............................7 74 6. IANA Considerations...................................7 75 7. Acknowledgments......................................7 76 8. References..........................................7 77 8.1. Normative References..............................7 78 Authors' Addresses......................................8 79 Intellectual Property Statement...........................8 80 Disclaimer of Validity...................................9 82 1. Motivation 84 MPLS-Ping [MPLS-Ping] can be used to detect faults along the LSP 85 path. One of the faults detected by MPLS-Ping is downstream link 86 failure, i.e. link connectivity being down. In some network 87 environment, source node also needs to know the condition of the link 88 on which the LSPs are carried even though the link connectivity is 89 up. That way the source LSR can perform needed functions, such as 90 enforcing admission control, re-signal and/or re-compute the LSP 91 path, or generate more stringent performance monitoring at shorter 92 interval, and etc. 94 A common example for the link condition change is the bandwidth 95 fluctuation in Mobile Backhaul network, where Microwave transport is 96 widely deployed. Most Microwave transport nodes adjust its bandwidth 97 based on the weather. Even though there is RSVP-TE for individual 98 links to advertise its available bandwidth in the routing domain, 99 end-to-end bandwidth change may not be possible in some Mobile 100 Backhaul environment, because there may be multiple routing domains 101 from base stations to MSO. If Source Nodes, i.e. LTE's eNodeB or 102 MSO's RNC, are aware of the bandwidth change, they can adjust 103 services accordingly, request other base stations to accept new 104 calls, or trigger a new Performance Monitoring scheme to track the 105 condition more closely. 107 In another application, source LSRs may want to be aware of the 108 congestion along the LSP path, so that proper actions can be taken. 109 MPLS-ECN (RFC 5129) specifies a mechanism for transit nodes to mark 110 EXP bits when congestion happens. However, many deployed MPLS 111 networks already use EXP bits to mark packet priorities, making MPLS- 112 ECN (RFC 5129) mechanism un-usable for the purpose of LSP change 113 indication. 115 In a third application, source LSRs may want to be aware of 116 significant performance degradation on the downstream links along the 117 LSP path. The performance degradation can be increased latency 118 and/or increased delay variation. Those performance degradations may 119 be induced by the physical layer protection scheme, such as link 120 switching from active side of the ring to protect side of the ring, 121 or it may be induced by transmission media degradation. 123 In a forth application, source LSRs may want to be aware of transport 124 media change on the downstream links along the LSP path. For 125 example, the link can be a fiber protected by microwave, and the 126 source router may be carrying an application that cannot use 127 microwave due to security concerns. 129 This draft suggests adding a new sub-TLV to the MPLS Ping Echo Reply 130 for the transit LSR to indicate the downstream link condition changes 131 to source routers. 133 2. MPLS-Ping extension for path condition impairment indication 135 [MPLS-Ping] specified that replying router for MPLS Ping should 136 include one Downstream Mapping for each interface, over which this 137 FEC could be forwarded, in the Echo Reply. [MPLS-Ping-Enhanced] has 138 introduced 3 types of sub-TLV to the Downstream Detailed Mapping, 139 Multipath data, Label stack, and FEC Stack change. 141 This draft suggests adding a new sub-TLV "Downstream Link Condition" 142 to indicate the condition of the downstream link of the corresponding 143 interface. The "Downstream Path Condition" could be bandwidth being 144 reduced, the interface being congested, etc. 146 Sub-Type Value Field 147 -------- -------- 148 TBD Multipath data (specified by [MPLS-Ping-Enhanced]) 149 TBD Label stack (specified by [MPLS-Ping-Enhanced]) 150 TBD FEC Stack change (specified by [MPLS-Ping-Enhanced]) 151 TBD Downstream Link Condition (new) 153 2.1. Downstream Link Condition sub-TLV 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length |ImpairmentType | SeverityLevel | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 The Impairment Type field can take one of the following values: 163 Value Meaning 164 -------- -------- 165 1 port towards downstream LSR is congested 166 2 Bandwidth of the link towards downstream LSR is reduced 167 3 performance of the link towards downstream LSR is reduced 168 4 transport media of the link towards downstream LSR has 169 been changed 171 The Severity Level field is a value indicating the severity of the 172 impairment. Network operator can set the Severity Level for 173 anticipated conditions and configure the proper actions at the source 174 node upon receiving the Echo Reply. For example, Severity Level 0 can 175 represent full bandwidth, 1 represents the next bandwidth level, and 176 6 represents the least bandwidth. For microwave transport link within 177 MPLS based Mobile Backhaul network, the Adaptive Modulation usually 178 has several levels of adjusted bandwidth, which can be used as the 179 basis for setting the Severity Level. 181 2.2. Link Condition Request in Echo Request 183 If a source LSR of a LSP cannot do anything when the LSP path is 184 impaired, then there is no point for the transit LSR to send any link 185 condition in the Echo Reply to the sender. Therefore, it is necessary 186 for the sender to indicate if it desires to receive the Downstream 187 Link Condition status in the Echo Reply. This draft suggests using 188 one reserved bit of DS flags in the Echo Request for the source node 189 to indicate if it desires to receive the impairment condition of the 190 downstream link on a transit LSR. 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | MTU | Address Type | DS Flags | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Downstream IP Address (4 or 16 octets) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Downstream Interface Address (4 or 16 octets) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Multipath Type| Depth Limit | Multipath Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 . . 204 . (Multipath Information) . 205 . . 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Downstream Label | Protocol | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 . . 210 . . 211 . . 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Downstream Label | Protocol | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 DS Flags 218 RFC4379 already defines I bit and N bit out of the octet DS Flags. 219 This draft suggests adding a new bit C for source LSR to indicate 220 if it desires to have the link impairment condition to be reported 221 by transit LSR in the Echo Reply. 223 The DS flags field is a bit vector with the following format: 224 0 1 2 3 4 5 6 7 225 +-+-+-+-+-+-+-+-+ 226 |Rsvd(MBZ)|C|I|N| 227 +-+-+-+-+-+-+-+-+ 229 I and N flags are already specified by RFC 4379. The C flag is 230 defined as follow: 232 Flag Name and Meaning 233 ----- ---------------- 234 C Source LSR desires to know the downstream link condition 236 When this flag is set (C = 1), it indicates that the replying 237 router SHOULD include the downstream link condition sub-TLV in the 238 echo reply message. When this flag is not set (C=0), it indicates 239 that the source LSR doesn't need downstream path condition 240 information, so replying router SHOULD NOT include the downstream 241 link condition sub-TLV in the echo reply. 243 2.3. Receiving Echo Request with a Path Condition Request flag set 245 If the DS flags' C is set, the receiving LSRs HAVE TO construct the 246 Downstream Link Condition sub-TLV and insert it into the Echo 247 Reply. 249 3. Receiving Path Condition Impairment Notification 251 Though it is out of the scope of this draft on what Source LSR will 252 do upon receiving the Path Condition in the Echo Reply, here are some 253 examples of possible actions Source LSR could do: 255 trigger more stringent performance monitoring in shorter 256 interval to measure the quality of the path 258 re-adjust load balancing among the multiple paths from Source 259 LSR to the Destination LSR 261 Re-signal LSP to alternative path 263 activate the secondary/protection path 265 adjust admission rate (in the case of LTE eNodeB) 267 Notify adjacent client device via E-LMI, IEEE802.3ah, or simple 268 flow control. 270 4. Manageability Considerations 272 This document does not add additional manageability considerations. 274 5. Security Considerations 276 This document has no additional requirement for a change to the 277 security models of MPLS-Ping and MPLS-Ping-Enhanced. 279 6. IANA Considerations 281 A future revision of this document will present requests to IANA for 282 codepoint allocation. 284 7. Acknowledgments 286 This document was prepared using 2-Word-v2.0.template.dot. 288 8. References 290 8.1. Normative References 292 [ECN] B. Davie, et. al., "Explicit Congestion Marking in MPLS", 293 RFC 5129, Jan. 2008. 295 [MPLS-PING] K. Kompella, et. al., "Detecting MPLS Data Plane 296 Failures", RFC 4379, February 2006. 298 [BFD-MPLS] Aggarwal, R., "draft-ietf-bfd-mpls-07.txt", work in 299 progress. 301 [LSP-Ping-Enhanced] N. Bahadur, et. al.,"Mechanism for performing 302 LSP-Ping over MPLS tunnels", "draft-ietf-mpls-lsp-ping- 303 enhanced-dsmap-04", work in progress. 305 Authors' Addresses 307 Linda Dunbar (Ed.) 308 Huawei Technologies 309 1700 Alma Drive, Suite 500 310 Plano, TX 75075, USA 311 Phone: (972) 543 5849 312 Email: ldunbar@huawei.com 314 Ning So (Ed.) 315 Enterprise Data Network and Traffic Planning 316 2400 N. Glenville Dr. 317 Richardson, TX 75082, USA 318 Phone: (972) 729 7905 319 Email: ning.so@verizonbusiness.com 321 Philippe Niger 322 France Telecom 323 2, avenue Pierre-Marzin 324 22307 Lannion Cedex 325 FRANCE 326 Email: philippe.niger@orange-ftgroup.com 328 Yannick Le Goff 329 France Telecom 330 2, avenue Pierre-Marzin 331 22307 Lannion Cedex 332 FRANCE 333 Email: yannick1.legoff@orange-ftgroup.com 335 Intellectual Property Statement 337 The IETF Trust takes no position regarding the validity or scope of 338 any Intellectual Property Rights or other rights that might be 339 claimed to pertain to the implementation or use of the technology 340 described in any IETF Document or the extent to which any license 341 under such rights might or might not be available; nor does it 342 represent that it has made any independent effort to identify any 343 such rights. 345 Copies of Intellectual Property disclosures made to the IETF 346 Secretariat and any assurances of licenses to be made available, or 347 the result of an attempt made to obtain a general license or 348 permission for the use of such proprietary rights by implementers or 349 users of this specification can be obtained from the IETF on-line IPR 350 repository at http://www.ietf.org/ipr 352 The IETF invites any interested party to bring to its attention any 353 copyrights, patents or patent applications, or other proprietary 354 rights that may cover technology that may be required to implement 355 any standard or specification contained in an IETF Document. Please 356 address the information to the IETF at ietf-ipr@ietf.org. 358 Disclaimer of Validity 360 All IETF Documents and the information contained therein are provided 361 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 362 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 363 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 364 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 365 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 366 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 367 FOR A PARTICULAR PURPOSE. 369 Acknowledgment 371 Funding for the RFC Editor function is currently provided by the 372 Internet Society.