idnits 2.17.1 draft-am-bfd-performance-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 21, 2017) is 2347 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mishra 3 Internet-Draft O3b Networks 4 Intended status: Standards Track M. Jethanandani 5 Expires: May 25, 2018 November 21, 2017 7 BFD Performance Measurement 8 draft-am-bfd-performance-00 10 Abstract 12 This document describes an extension to the Bidirectional Forwarding 13 Detection (BFD) protocol to determine the optimal BFD transmit 14 interval for links with high one-way delay. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 25, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. BFD Performance TLV . . . . . . . . . . . . . . . . . . . . . 3 59 4. Theory of Operations . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Consideration . . . . . . . . . . . . . . . . . . . 5 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 The Bidirectional Forwarding Detection (BFD) [RFC5880] protocol 68 operates by transmitting and receiving control frames, generally at 69 high frequency, over the datapath being monitored. In order to 70 prevent significant data loss due to a datapath failure, the 71 tolerance for lost or delayed frames in the Detection Time, as 72 defined in BFD [RFC5880] is set to the smallest feasible value. 74 This document proposes a mechanism to determine the smallest BFD 75 transmit interval that can be supported on the link. This is 76 achieved by actively measuing the one-way delay for each BFD session 77 and setting the BFD session intervals based on the measured delay. 78 This allows the BFD session to adapt to the fastest rate feasible on 79 the current active path. 81 2. Use Cases 83 To ensure stability, the BFD interval is typically set to value 84 greater than the one-way delay of the link. This value is currently 85 manually tuned based on the largest one-way delay in the set of links 86 over which the session can be established. 88 The method described in this proposal is useful in networks where the 89 network latency is high, or varies with time. Trans-oceanic links 90 and connectivity over geo-synchronous satellites are typical examples 91 of links where the latency is high and the difference in latency on 92 primary and backup paths can be significant. 94 Another use-case is connectivity using satellites in mid-earth orbit 95 (MEO) or low-earth orbit (LEO). In these systems the one-way delay, 96 while it is low (25msec to 150 msec), varies with time. This 97 variation, based on various factors, can be as high as 30 msec. With 98 mobile receivers, such as ships, the delay when using such 99 connectivity can be non-trivial to predict. This requires an 100 automated method to determine the optimal BFD interval to allow 101 fastest possible recovery in case of failure. 103 Many networks employ the use of diverse link types for redundancy 104 where each link has significantly different link characteristics. 105 For example, using geo-stationary orbit (GEO) satellite backup for 106 MEO/LEO connectivity, or using fibre backup for MEO connectivity. 107 The end-to-end BFD sessions for services running on top of the 108 diverse transport will benefit from adaptive BFD rate. 110 3. BFD Performance TLV 112 The functionality proposed for BFD performance measurement is 113 achieved by proposing a new BFD Performance TLV to the BFD control 114 frame. This TLV leverages the delay measurement method defined in 115 RFC 6374 [RFC6374]. As BFD Version 1 control frame does not have 116 unused flags, the BFD Performance TLV overloads the BFD 117 Authentication Flag and uses a new auth type BFDP-AUTH-TYPE (code- 118 point TBA). The BFD Performance TLV merges the MPLS delay 119 measurement message with the BFD authentication TLV (while removing 120 fields that are not required for this application) 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Auth Type | Auth Len |Version| Flags | Control Code | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | QTF | RTF | RPTF | Reserved | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Timestamp 1 | 130 | | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Timestamp 2 | 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Timestamp 3 | 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Timestamp 4 | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: BFD Performance TLV 144 where: 146 Auth Type: The Authentication Type, which in this case is BFDP-AUTH- 147 TYPE (value to be assigned). 149 Auth Len: The length of the Authentication Section, in bytes. 151 Version: Currently set to 0. 153 Flags: As specified in Section 3.1 of RFC 6374 [RFC6374]. The T flag 154 is set to 1. 156 Control Code: As specified in Section 3.1 of RFC 6374 [RFC6374]. 158 QTF: Querier Timestamp Format. The format of the timestamp values 159 written by the querier, as specified in Section 3.4 of RFC 6374 160 [RFC6374]. 162 RTF: Responder Timestamp Format. The format of the timestamp values 163 written by the responder, as specified in Section 3.4 of RFC 6374 164 [RFC6374]. 166 RPTF: Responder's Preferred Timestamp Format. The timestamp format 167 preferred by the responder, as specified in Section 3.4 of RFC 6374 168 [RFC6374]. 170 Timestamp 1-4: Referring to Section 2.4 of RFC 6374 [RFC6374], when a 171 query is sent from A, Timestamp 1 is set to T1 and the other 172 timestamp fields are set to 0. When the query is received at B, 173 Timestamp 2 is set to T2. At this point, B copies Timestamp 1 to 174 Timestamp 3 and Timestamp 2 to Timestamp 4, and re-initializes 175 Timestamp 1 and Timestamp 2 to 0. When B transmits the response, 176 Timestamp 1 is set to T3. When the response is received at A, 177 Timestamp 2 is set to T4. The actual formats of the timestamp fields 178 written by A and B are indicated by the Querier Timestamp Format and 179 Responder Timestamp Format fields respectively. 181 The mapping of timestamps to the Timestamp 1-4 fields is designed to 182 ensure that transmit timestamps are always written at the same fixed 183 offset in the packet, and likewise for receive timestamps. This 184 property is important for hardware processing. 186 4. Theory of Operations 188 This delay measurement follows the method defined in Section 2.4 of 189 RFC 6374 [RFC6374]. 191 The message is classified using the BFD authentication method defined 192 in RFC5880 [RFC5880]. 194 Method for determining the optimal BFD interval for a link with 195 certain delay charateristics is implementation specific and beyond 196 the scope of this document. 198 5. IANA Requirements 200 Requesting new BFD Authentication Type for BFD Performance TLV. 202 6. Security Consideration 204 Other than concerns raised in BFD [RFC5880], there are no new 205 concerns with this proposal. 207 7. Normative References 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, 211 DOI 10.17487/RFC2119, March 1997, 212 . 214 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 215 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 216 . 218 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 219 Measurement for MPLS Networks", RFC 6374, 220 DOI 10.17487/RFC6374, September 2011, 221 . 223 Authors' Addresses 225 Ashesh Mishra 226 O3b Networks 228 Email: mishra.ashesh@gmail.com 230 Mahesh Jethanandani 232 Email: mjethanandani@gmail.com