idnits 2.17.1 draft-ietf-ippm-type-p-monitor-03.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 draft header indicates that this document updates RFC5357, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5357, updated by this document, for RFC5378 checks: 2005-11-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 4, 2015) is 3095 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hedin 3 Internet-Draft G. Mirsky 4 Updates: 5357 (if approved) S. Baillargeon 5 Intended status: Standards Track Ericsson 6 Expires: May 7, 2016 November 4, 2015 8 Differentiated Service Code Point and Explicit Congestion Notification 9 Monitoring in Two-Way Active Measurement Protocol (TWAMP) 10 draft-ietf-ippm-type-p-monitor-03 12 Abstract 14 This document describes an optional extension for Two-Way Active 15 Measurement Protocol (TWAMP) allowing the monitoring of the 16 Differentiated Service Code Point and Explicit Congestion 17 Notification fields with the TWAMP-Test protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 7, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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 Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. TWAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Setting Up Connection to Monitor DSCP and ECN . . . . . . 3 59 2.2. TWAMP-Test Extension . . . . . . . . . . . . . . . . . . 4 60 2.2.1. Session-Reflector Packet Format for DSCP and ECN 61 Monitoring . . . . . . . . . . . . . . . . . . . . . 4 62 2.2.2. DSCP and ECN Monitoring with RFC 6038 extensions . . 7 63 2.2.3. Consideration for TWAMP Light mode . . . . . . . . . 8 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 6.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines the 75 Type-P Descriptor field and negotiation of its value in OWAMP-Control 76 protocol. The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] 77 states that only a Differentiated Services Code Point (DSCP) 78 [RFC2474], [RFC3168], [RFC3260] value can be defined by Type-P 79 Descriptor and the negotiated value must be used by both Session- 80 Sender and Session-Reflector. The TWAMP specification also states 81 that the same DSCP value (found in the Session-Sender packet) MUST be 82 used in the test packet reflected by the Session-Reflector. However 83 the TWAMP-Test protocol does not specify any methods to determine or 84 report when the DSCP value has changed or is different than expected 85 in the forward or reverse direction. Re-marking the DSCP (changing 86 its original value) in IP networks is possible and often accomplished 87 by a Differentiated Services policy configured on a single node along 88 the IP path. In many cases, a change of the DSCP value indicates an 89 unintentional or erroneous behavior. At best, the Session-Sender can 90 detect a change of the DSCP reverse direction assuming such change is 91 actually detectable. 93 This document describes an OPTIONAL feature for TWAMP. It is called 94 the DSCP and ECN Monitoring. It allows the Session-Sender to know 95 the actual DSCP value received at the Session-Reflector. Furthermore 96 this feature tracks the Explicit Congestion Notification (ECN) 97 [RFC2474], [RFC3168], [RFC3260] value received at the Session- 98 Reflector. This is helpful to determine if ECN is actually operating 99 or if an ECN-capable node has detected congestion in the forward 100 direction. 102 1.1. Conventions used in this document 104 1.1.1. Terminology 106 DSCP: Differentiated Services Code Point 108 ECN: Explicit Congestion Notification 110 IPPM: IP Performance Measurement 112 TWAMP: Two-Way Active Measurement Protocol 114 OWAMP: One-Way Active Measurement Protocol 116 1.1.2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119]. 123 2. TWAMP Extensions 125 TWAMP connection establishment follows the procedure defined in 126 Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357] where the Modes 127 field is used to identify and select specific communication 128 capabilities. At the same time the Modes field been recognized and 129 used as an extension mechanism [RFC6038]. The new feature requires a 130 new flag to identify the ability of a Session-Reflector to return 131 value of received DSCP and ECN values back to a Session-Sender, and 132 to support the new Session-Reflector packet format in the TWAMP-Test 133 protocol. See the Section 3 for details on the assigned bit 134 position. 136 2.1. Setting Up Connection to Monitor DSCP and ECN 138 The Server sets the DSCP and ECN Monitoring flag in the Modes field 139 of the Server Greeting message to indicate its capabilities and 140 willingness to monitor them. If the Control-Client agrees to monitor 141 DSCP and ECN on some or all test sessions invoked with this control 142 connection, it MUST set the DSCP and ECN Monitoring flag in the Modes 143 field in the Setup Response message. 145 2.2. TWAMP-Test Extension 147 Monitoring of DSCP and ECN requires support by the Session-Reflector 148 and changes the test packet format in all the original 149 (unauthenticated, authenticated and encrypted) modes. Monitoring of 150 DSCP and ECN does not alter the Session-Sender test packet format but 151 certain considerations must be taken when and if this mode is 152 accepted in combination with Symmetrical Size mode [RFC6038]. 154 2.2.1. Session-Reflector Packet Format for DSCP and ECN Monitoring 156 When the Session-Reflector supports DSCP and ECN Monitoring it 157 constructs the Sender DSCP and ECN (S-DSCP-ECN) field, presented in 158 Figure 1, for each test packet it sends to Session-Sender according 159 to the following procedure: 161 o the six (least-significant) bits of the Differentiated Service 162 field MUST be copied from received Session-Sender test packet into 163 Sender DSCP (S-DSCP) field; 165 o the two bits of the ECN field MUST be copied from received 166 Session-Sender test packet into Sender ECN (S-ECN) field. 168 0 1 2 3 4 5 6 7 169 +---+---+---+---+---+---+---+---+ 170 | S-DSCP | S-ECN | 171 +---+---+---+---+---+---+---+---+ 173 Figure 1: Sender DSCP and ECN field format 175 Formats of the test packet transmitted by the Session-Reflector in 176 unauthenticated, authenticated and encrypted modes been defined in 177 Section 4.2.1 [RFC5357]. For the Session-Reflector that supports 178 DSCP and ECN Monitoring these formats are displayed in Figure 2 and 179 Figure 3. 181 For unauthenticated mode: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Sequence Number | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Timestamp | 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Error Estimate | MBZ | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Receive Timestamp | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Sender Sequence Number | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Sender Timestamp | 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Sender Error Estimate | MBZ | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Sender TTL | S-DSCP-ECN | MBZ | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 ~ Packet Padding ~ 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2: Session-Reflector test packet format with DSCP and ECN 211 Monitoring in unauthenticated mode 213 The DSCP and ECN values (part of the Type-P Descriptor [RFC4656]) can 214 be provisioned through TWAMP-Control or by other means (CLI or 215 Central Controller). The DSCP and ECN values are often copied into 216 reflected test packets with current TWAMP implementations without 217 TWAMP-Control protocol. With DSCP and ECN Monitoring Extension, the 218 Session-Reflector handles DSCP as following: 220 o the Session-Reflector MUST extract the DSCP and ECN values from 221 the received packet and MUST populate with them S-DSCP-ECN field 222 of the corresponding reflected packet; 224 o the Session-Reflector MUST transmit each reflected test packet 225 with DSCP set to the provisioned value; 227 o if the provisioned DSCP value is not known (e.g. TWAMP Light), 228 the choice of the DSCP is implementation specific. For instance, 229 Session-Reflector MAY copy the DSCP value from the received test 230 packet and set it as DSCP in a reflected packet. Alternatively 231 Session-Reflector MAY set DSCP value to CS0 (zero) [RFC2474]; 233 o if the provisioned ECN value is not known, ECN SHOULD be set to 234 Not-ECT codepoint value [RFC3168]. Otherwise, the provisioned ECN 235 value for the session SHALL be used. 237 A Session-Reflector in the DSCP and ECN Monitoring mode does not 238 analyze, nor acts on ECN value of the received TWAMP test packet and 239 therefore ignores congestion indications from the network. It is 240 expected that sending rates are low enough, as TWAMP deployment 241 experience had demonstrated since TWAMP base RFC 5357 publication in 242 2008, that ignoring these congestion indications will not 243 significantly contribute to network congestion. 245 For authenticated and encrypted modes: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Sequence Number | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | MBZ (12 octets) | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Timestamp | 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Error Estimate | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 261 | MBZ (6 octets) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Receive Timestamp | 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MBZ (8 octets) | 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Sender Sequence Number | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 | MBZ (12 octets) | 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Sender Timestamp | 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Sender Error Estimate | | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 280 | MBZ (6 octets) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Sender TTL | S-DSCP-ECN | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 284 | | 285 | MBZ (14 octets) | 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 | HMAC (16 octets) | 290 | | 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | 294 ~ Packet Padding ~ 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: Session-Reflector test packet format with DSCP and ECN 299 Monitoring in authenticated or encrypted modes 301 2.2.2. DSCP and ECN Monitoring with RFC 6038 extensions 303 [RFC6038] defined two extensions to TWAMP. First, to ensure that 304 Session-Sender and Session-Reflector exchange TWAMP-Test packets of 305 equal size. Second, to specify number of octets to be reflected by 306 Session-Reflector. If DSCP and ECN Monitoring and Symmetrical Size 307 and/or Reflects Octets modes are being negotiated between Server and 308 Control-Client in Unauthenticated mode, then, because Sender DSCP and 309 Sender ECN increase size of unauthenticated Session-Reflector packet 310 by 4 octets, the Padding Length value SHOULD be >= 28 octets to allow 311 for the truncation process that TWAMP recommends in Section 4.2.1 of 312 [RFC5357]. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sequence Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Timestamp | 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Error Estimate | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 324 | | 325 | MBZ (28 octets) | 326 | | 327 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 330 | | 331 . . 332 . Packet Padding . 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4: Session-Sender test packet format with DSCP and ECN 337 Monitoring and Symmetrical Test Packet in unauthenticated mode 339 2.2.3. Consideration for TWAMP Light mode 341 Appendix I of [RFC5357] does not explicitly state how the value of 342 the Type-P Descriptor is synchronized between Session-Sender and 343 Session-Reflector and whether different values are considered as 344 error condition and SHOULD be reported. We assume that by some means 345 the Session-Sender and the Session-Reflector of the given TWAMP-Test 346 session been informed to use the same DSCP value. Same means, i.e. 347 configuration, could be used to inform Session-Reflector to support 348 DSCP and ECN Monitoring mode by copying data from received TWAMP test 349 packets. Then Session-Sender may be informed to use Sender DSCP and 350 ECN field in reflected TWAMP test packet. 352 3. IANA Considerations 354 The TWAMP-Modes registry defined in [RFC5618]. 356 IANA is requested to reserve a new DSCP and ECN Monitoring Capability 357 as follows: 359 +-----+------------------------+---------------------+--------------+ 360 | Bit | Description | Semantics | Reference | 361 | | | Definition | | 362 +-----+------------------------+---------------------+--------------+ 363 | TBA | DSCP and ECN | Section 2 | This | 364 | | Monitoring Capability | | document | 365 +-----+------------------------+---------------------+--------------+ 367 Table 1: New Type-P Descriptor Monitoring Capability 369 4. Security Considerations 371 Monitoring of DSCP and ECN does not appear to introduce any 372 additional security threat to hosts that communicate with TWAMP as 373 defined in [RFC5357], and existing extensions [RFC6038]. Sections 374 such as 3.2, 4., 4.1.2, 4.2, and 4.2.1 of [RFC5357] discuss 375 unauthenticated, authenticated, and encrypted modes in varying 376 degrees of detail. The security considerations that apply to any 377 active measurement of live networks are relevant here as well. See 378 the Security Considerations sections in [RFC4656] and [RFC5357]. 380 5. Acknowledgements 382 Authors greatly appreciate thorough review and thoughtful comments by 383 Bill Cerveny, Christofer Flinta and Samita Chakrabarti. 385 6. References 387 6.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 395 "Definition of the Differentiated Services Field (DS 396 Field) in the IPv4 and IPv6 Headers", RFC 2474, 397 DOI 10.17487/RFC2474, December 1998, 398 . 400 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 401 of Explicit Congestion Notification (ECN) to IP", 402 RFC 3168, DOI 10.17487/RFC3168, September 2001, 403 . 405 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 406 Zekauskas, "A One-way Active Measurement Protocol 407 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 408 . 410 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 411 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 412 RFC 5357, DOI 10.17487/RFC5357, October 2008, 413 . 415 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 416 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 417 DOI 10.17487/RFC5618, August 2009, 418 . 420 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 421 Protocol (TWAMP) Reflect Octets and Symmetrical Size 422 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 423 . 425 6.2. Informative References 427 [RFC3260] Grossman, D., "New Terminology and Clarifications for 428 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 429 . 431 Authors' Addresses 433 Jonas Hedin 434 Ericsson 436 Email: jonas.hedin@ericsson.com 438 Greg Mirsky 439 Ericsson 441 Email: gregory.mirsky@ericsson.com 443 Steve Baillargeon 444 Ericsson 446 Email: steve.baillargeon@ericsson.com