idnits 2.17.1 draft-dunbar-bfd-path-condition-change-marking-00.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. ** There are 7 instances of too long lines in the document, the longest one being 135 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2010) is 5210 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: 'RFC4379' is mentioned on line 251, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Missing Reference: 'RFC 4379' is mentioned on line 265, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Missing Reference: 'MPLS-Ping-Enhanced' is mentioned on line 275, but not defined == Unused Reference: 'ECN' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'MPLS-PING' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'BFD-MPLS' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'BFD' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'LSP-Ping-Enhanced' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1au' is defined on line 345, 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' == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-09 -- Possible downref: Non-RFC (?) normative reference: ref. 'LSP-Ping-Enhanced' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft Huawei 3 N. So 4 Verizon 5 Intended status: Standard Track 6 Expires: July 2010 8 January 19, 2010 10 Path Condition Change Marking using BFD 12 draft-dunbar-bfd-path-condition-change-marking-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 This Internet-Draft will expire on July 19, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the BSD License. 52 Abstract 54 There are times that an LSP source node needs to know change(s) has 55 occurred along the originally established LSP path. This is 56 especially true in the Mobile Backhaul environment where microwave 57 transport is widely deployed. The bandwidth provided by the microwave 58 transport can change with weather. The source LSR, e.g. LTE's eNodeB, 59 needs to adjust its admission rate or shift more load to alternative 60 paths when the backhaul transport path condition is changed. 62 This draft describes a simple mechanism for transit LSRs to notify 63 Source LSR of the path condition changes. 65 Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC-2119 0. 71 Table of Contents 73 1. Motivation..................................................3 74 2. Analysis of potential methods................................3 75 3. BFD protocol extension for path condition impairment notification 76 ...............................................................4 77 4. Path Condition Impairment Notification.......................6 78 5. Receiving Path Condition Impairment Notification.............7 79 6. Manageability Considerations.................................7 80 7. Security Considerations......................................8 81 8. IANA Considerations.........................................8 82 9. Acknowledgments.............................................8 83 10. References.................................................8 84 10.1. Normative References...................................8 85 10.2. Informative References.................................8 86 Authors' Addresses.............................................9 87 Intellectual Property Statement.................................9 88 Disclaimer of Validity........................................10 90 1. Motivation 92 LSP's source node(s) can have multiple paths to the corresponding 93 destination node(s). Those paths can have different performance 94 behavior such as delay, delay variation, bandwidth, and so on. The 95 LSP(s)' can carry traffic with various Class of Services (CoS). Some 96 of the premium CoS require strict performance objectives to be met at 97 all time, so it is desirable to have LSP's source node(s) to be 98 notified if there is any condition change along the LSP path. That 99 way the source node(s), which is aware of the performance objectives, 100 can make the proper decision if an alternative path needs to be 101 established, or the admission rate needs to be changed for the 102 incoming traffic. 104 A common example for the LSP condition change is the bandwidth 105 fluctuation in Mobile Backhaul network, where Microwave transport is 106 widely deployed. Most Microwave transport nodes adjust its bandwidth 107 based on the weather. Even though there is RSVP-TE for individual 108 links to advertise its available bandwidth to all the nodes in the 109 routing domain, RSVP-TE might not be possible in some Mobile Backhaul 110 environment where there might be multiple routing domains from base 111 stations to MSO. If Source Nodes, i.e. LTE's eNodeB, are aware of the 112 bandwidth change, they can adjust services accepted to the network, 113 request other base stations to accept new calls, or trigger (or 114 increase the frequency of) Performance Monitoring scheme. 116 In other applications, some source LSRs want to get notified when 117 there is congestion condition or port changes on the transit nodes, 118 so that proper actions can be taken. MPLS-ECN (RFC 5129) specifies a 119 mechanism for transit nodes to mark EXP bits when congestion happens. 120 However, many deployed MPLS networks already use EXP bits to mark 121 priority, making it not possible to use MPLS-ECN (RFC 5129) mechanism 122 for the purpose of LSP change notification. 124 2. Analysis of potential methods 126 There is MPLS-ECN (RFC 5129) marking on the MPLS header's EXP field 127 when transit nodes encounter congestion. The problem with MPLS-ECN 128 (RFC 5129) is that many deployed MPLS networks already use EXP bits 129 to represent priority. Another issue with MPLS-ECN (RFC 5129) is that 130 the congestion marking doesn't occur until congestion happens. When a 131 transit link bandwidth is reduced, such as microwave transport link 132 bandwidth reduction due to weather, queues on the transit node can 133 quickly build up. Even if MPLS-ECN (RFC 5129) scheme is used, the 134 queue on the transit node may already been overrun by the time the 135 egress node recognizing the congestion and notifies the source node. 137 When there is a hard event change on a transit LSR, such as bandwidth 138 reduction or port change, an alternative approach is for the transit 139 LSR to send a simple notification to the source node indicating the 140 change occurred. However, the transit nodes may not know the source 141 nodes of the LSPs (e.g. LDP LSPs). Although the transit LSR can get 142 the source LSR's IP address from the MPLS-Ping Request message, the 143 MPLS-Ping may not be triggered when there is condition change on the 144 LSP path. 146 Another alternative is to mark on the MPLS header to indicate the 147 hard impairment event occurred on the path. It is the similar 148 approach as the MPLS-ECN (RFC5129). However, there are no available 149 bits on the MPSL header for such marking. 151 3. BFD protocol extension for path condition impairment notification 153 When periodic BFD is enabled between a pair of LSRs (the Source and 154 the destination), the BFD frequency is based on a fixed interval, 155 usually in the magnitude of milliseconds. Since MPLS-BFD is intended 156 to traverse along the LSP path, a transit node has the information on 157 the port to the downstream LSR and is aware of the downstream link 158 status, including impairment status, such as bandwidth being reduced, 159 port being altered, or congested. Therefore, BFD is a good choice for 160 path condition impairment notification when BFD is enabled on the 161 LSP. 163 This draft suggests adding an optional Impairment section to the BFD 164 Control Frame: 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Type | Length |ImpairmentValue| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Optional Routable IPV4 or IPV6 address of source LSR | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 If a source LSR of a LSP cannot do anything when the LSP path is 175 impaired, then the source LSR SHOULD NOT include this optional 176 section in the BFD control frame. When the Impairment section is not 177 present in the BFD control frame, the transit LSR does not need to 178 mark the path condition change indication. 180 If the Source LSR can do something when the normal LSP path is 181 impaired or altered, the Source LSR CAN include the optional 182 Impairment section in the BFD Control Frame. If the Impairment 183 section is attached, the transit LSR CAN do the following when 184 experiencing downstream link impairment: 186 The transit LSR SHOULD mark on the Impairment field of the 187 condition of downstream link, and/or 189 The transit LSR SHALL send a Path Condition Impairment 190 Notification (PCIN) back to the source LSR if it knows the 191 source LSR. 193 The Impairment Value field can take one of the following values: 195 Value Meaning 196 -------- -------- 197 1 port towards downstream LSR is congested 198 2 Bandwidth of the link towards downstream LSR is reduced 199 3 Port towards downstream LSR has been altered 201 The optional Routable IP address in the Impairment Section is for 202 transit LSR to send the Path Condition Impairment Notification back 203 to the source LSR. Since BFD control frames between a pair of LSRs 204 are exchanged frequently, it is not necessary for the transit node to 205 send the Path Condition Impairment Notification every time there is 206 BFD traversed. In order to minimize work required on transit node, 207 source node takes the responsibility to indicate if it needs a 208 notification from transit node when the transit node experiences 209 downstream link impairment. When the Routable IP address is included 210 in the Impairment Section of BFD control frame, transit node SHALL 211 send back a Path Condition Impairment Notification to the Source LSR 212 when impairment is encountered. 214 The source LSR CAN perform the following actions upon receiving the 215 Path Condition Impairment Notification from transit LSR. 217 send more sophisticated inquiry messages to the transit LSR to 218 diagnose what happened 220 trigger performance monitoring scheme to measure the quality of 221 the path 223 re-adjust load balancing among the multiple paths from Source 224 LSR to the Destination LSR 226 Re-signal LSP to alternative path 227 activate the secondary/protection path 229 reduce admission rate (in the case of LTE eNodeB). 231 When a transit node receives a BFD and its downstream link is 232 impaired or altered, it CAN perform the following actions: 234 1. If the BFD doesn't have the Impairment section, do nothing. 235 Simply forward the BFD to the next hop. 237 Otherwise: 239 2. The transit node SHALL set the ImpairmentValue field accordingly 240 and then forward the BFD to the next hop. 242 3. If Routable IP address is included in the Impairment section, 243 the transit LSR SHALL construct the Path Condition Impairment 244 Notification message and send it to the Source LSR. 246 4. Path Condition Impairment Notification 248 Though a new message format can be specified for transit node to send 249 the Path Condition Impairment Notification, it is always easier for 250 LSR to use an existing message type, like LSP-Ping Echo Reply 251 [RFC4379], with some minor modification to do the job. 253 This draft suggests a message type similar to the MPLS-Ping Echo 254 reply which is specified in Section 3 of RFC 4379 to indicate the 255 Path Condition Impairment Notification with the following changes: 257 RFC 4379 specifies that the Message Type of the LSP-Ping has one of 258 the two values. This draft suggests adding a new value to indicate 259 that the message is for Path Condition Impairment Notification in 260 responding to BFD: 262 Value Meaning 263 -------- -------- 264 1 MPLS echo request [RFC 4379] 265 2 MPLS echo reply [RFC 4379] 266 3 Path Condition Impairment Notification in responding to 267 BFD 269 [MPLS-Ping-Enhanced] introduced Downstream Detailed Mapping TLV. This 1 draft suggests adding a new "Downstream Path Condition" sub-TLV to 270 reflect the condition of the downstream link. When used alone, path 271 condition impairment notification SHALL be activated upon receiving a 272 BFD control Frame with the optional Routable IP Address included in 273 the Impairment Section. In this case, the Downstream Path Condition 274 sub-TLV SHALL be the only sub-TLV in the Downstream Detailed Map 275 [MPLS-Ping-Enhanced]. When the downstream path condition is included 276 as a sub-type, the Return Code of the echo response message SHALL be 277 set to "See DDM TLV for Return Code and Return SubCode". 279 Downstream Path Condition Impairment sub-TLV SHOULD have the 280 following field: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |PathCondSubType| Length |ImpairmentValue| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | BFD control Header field | 288 (All the head fields until My Discriminator, Your Discriminator) 289 * * 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The ImpairmentValue is same as the value used in the BFD control 294 (section 3 above). 296 5. Receiving Path Condition Impairment Notification 298 It is out of the scope of this draft on what Source LSR will do upon 299 receiving the Path Condition Impairment Notification. 301 6. Manageability Considerations 303 This document does not add additional manageability considerations. 305 1 The Downstream Path Condition sub-TLV can also be included in the normal LSP-Ping 306 response to indicate that the downstream link, even though its connectivity is up, 307 is impaired. This will be a separate draft amending the MPLS-Ping-Enhanced scheme. 309 7. Security Considerations 311 This document has no requirement for a change to the security models 312 within BFD. 314 8. IANA Considerations 316 A future revision of this document will present requests to IANA for 317 codepoint allocation. 319 9. Acknowledgments 321 This document was prepared using 2-Word-v2.0.template.dot. 323 10. References 325 10.1. Normative References 327 [ECN] B. Davie, et. al., "Explicit Congestion Marking in MPLS", 328 RFC 5129, Jan. 2008. 330 [MPLS-PING] K. Kompella, et. al., "Detecting MPLS Data Plane 331 Failures", RFC 4379, February 2006. 333 [BFD-MPLS] Aggarwal, R., "draft-ietf-bfd-mpls-07.txt", work in 334 progress. 336 [BFD] Katz, D. and Ward, D., "Bidirectional Forwarding Detection", 337 draft-ietf-bfd-base-09.txt 339 [LSP-Ping-Enhanced] N. Bahadur, et. al.,"Mechanism for performing 340 LSP-Ping over MPLS tunnels", "draft-ietf-mpls-lsp-ping- 341 enhanced-dsmap-04", work in progress. 343 10.2. Informative References 345 [IEEE802.1au] IEEE802.1au Virtual Bridged Local Area Networks- 346 Amendment: Congestion Notification 348 Authors' Addresses 350 Linda Dunbar (Ed.) 351 Huawei Technologies 352 1700 Alma Drive, Suite 500 353 Plano, TX 75075, USA 354 Phone: (972) 543 5849 355 Email: ldunbar@huawei.com 357 Ning So (Ed.) 358 Enterprise Data Network and Traffic Planning 359 2400 N. Glenville Dr. 360 Richardson, TX 75082, USA 361 Phone: (972) 729 7905 362 Email: ning.so@verizonbusiness.com 364 Intellectual Property Statement 366 The IETF Trust takes no position regarding the validity or scope of 367 any Intellectual Property Rights or other rights that might be 368 claimed to pertain to the implementation or use of the technology 369 described in any IETF Document or the extent to which any license 370 under such rights might or might not be available; nor does it 371 represent that it has made any independent effort to identify any 372 such rights. 374 Copies of Intellectual Property disclosures made to the IETF 375 Secretariat and any assurances of licenses to be made available, or 376 the result of an attempt made to obtain a general license or 377 permission for the use of such proprietary rights by implementers or 378 users of this specification can be obtained from the IETF on-line IPR 379 repository at http://www.ietf.org/ipr 381 The IETF invites any interested party to bring to its attention any 382 copyrights, patents or patent applications, or other proprietary 383 rights that may cover technology that may be required to implement 384 any standard or specification contained in an IETF Document. Please 385 address the information to the IETF at ietf-ipr@ietf.org. 387 Disclaimer of Validity 389 All IETF Documents and the information contained therein are provided 390 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 391 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 392 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 393 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 394 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 395 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 396 FOR A PARTICULAR PURPOSE. 398 Acknowledgment 400 Funding for the RFC Editor function is currently provided by the 401 Internet Society.