idnits 2.17.1 draft-morton-ippm-owamp-registry-01.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 RFC4656, 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 RFC4656, updated by this document, for RFC5378 checks: 2000-11-22) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2015) is 3189 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ipsec-10 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Updates: 4656 (if approved) July 6, 2015 5 Intended status: Standards Track 6 Expires: January 7, 2016 8 Registries for the One-Way Active Measurement Protocol - OWAMP 9 draft-morton-ippm-owamp-registry-01 11 Abstract 13 This memo describes the registries for OWAMP - the One-Way Active 14 Measurement Protocol. The registries allow assignment of MODE bit 15 positions and OWAMP Command numbers. The memo also requests that 16 IANA establish the registries for new features, called the OWAMP- 17 Modes registry and the OWAMP Control Command Number registry. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 73 3. IANA Considerations for OWAMP Control Registries . . . . . . 3 74 3.1. Control Command Number Registry . . . . . . . . . . . . . 3 75 3.1.1. Registry Specification . . . . . . . . . . . . . . . 3 76 3.1.2. Registry Management . . . . . . . . . . . . . . . . . 3 77 3.1.3. Experimental Numbers . . . . . . . . . . . . . . . . 4 78 3.1.4. OWAMP-Control Command Numbers Initial Contents . . . 4 79 3.2. OWAMP-Modes . . . . . . . . . . . . . . . . . . . . . . . 4 80 3.2.1. Registry Specification . . . . . . . . . . . . . . . 4 81 3.2.2. Registry Management . . . . . . . . . . . . . . . . . 4 82 3.2.3. Experimental Numbers . . . . . . . . . . . . . . . . 5 83 3.2.4. OWAMP-Modes Initial Contents . . . . . . . . . . . . 5 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 88 6.2. Informative References . . . . . . . . . . . . . . . . . 6 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 91 1. Introduction 93 The One-way Active Measurement Protocol, OWAMP [RFC4656] was prepared 94 to support measurements of metrics specified by the IP Performance 95 Metrics (IPPM) working group in the IETF. The Two-Way Active 96 Measurement Protocol, TWAMP [RFC5357] is an extension of OWAMP. The 97 TWAMP specification gathered wide review as it approached completion, 98 and the by-products were several recommendations for new features in 99 TWAMP. As a result, a registry of new features was established for 100 TWAMP. However, there were no new features proposed for OWAMP until 101 recently. 103 This memo establishes the needed registries for OWAMP, and updates 104 [RFC4656]. 106 2. Purpose and Scope 108 The purpose and scope of this memo is to describe and request the 109 establishment of registries for future OWAMP [RFC4656] extensions. 110 IANA already administrates the "Two-way Active Measurement Protocol 111 (TWAMP) Parameters", and this request follows a similar form (with 112 one exception identified below). 114 This memo also provides the initial contents for the registries. 116 3. IANA Considerations for OWAMP Control Registries 118 OWAMP-Control protocol coordinates the measurement capability. All 119 OWAMP-Control messages follow specifications defined in section 3 of 120 [RFC4656]. 122 3.1. Control Command Number Registry 124 IANA is requested to create a OWAMP-Control Command Number registry. 126 OWAMP-Control Commands follow specifications defined in section 3.4 127 of [RFC4656]. 129 3.1.1. Registry Specification 131 OWAMP-Control Commands Numbers are specified in the first octet of 132 OWAMP-Control-Client command messages consistent with section 3 of 133 [RFC4656]. There are a maximum of 256 command numbers. 135 3.1.2. Registry Management 137 Because the "OWAMP-Control Command Numbers" registry can contain only 138 256 values, and because OWAMP is an IETF protocol, these registries 139 must be updated only by "IETF Consensus" as specified in [RFC5226] 140 (an RFC that documents registry use and is approved by the IESG). 142 3.1.3. Experimental Numbers 144 One experimental value is currently assigned in the Command Numbers 145 Registry, as indicated in the initial contents below. 147 3.1.4. OWAMP-Control Command Numbers Initial Contents 149 OWAMP-Control Commands follows the procedure defined in section 3.5 150 of [RFC4656] (and in the remainder of section 3). 152 The complete set of OWAMP-Control Command Numbers are as follows 153 (including one reserved bit position): 155 OWAMP-Control Command Numbers Registry 157 Value Description Semantics Definition 158 0 Reserved 159 1 Request-Session RFC 4656, Section 3.5 160 2 Start-Sessions RFC 4656, Section 3.7 161 3 Stop-Sessions RFC 4656, Section 3.8 162 4 Fetch-Sessions RFC 4656, Section 3.9 163 5 Experimentation This Memo 164 6-255 Unassigned 166 3.2. OWAMP-Modes 168 IANA is requested to create a OWAMP-Modes registry. 170 3.2.1. Registry Specification 172 OWAMP-Modes are specified in OWAMP Server Greeting messages and Set- 173 up Response messages consistent with section 3.1 of [RFC4656]. Modes 174 are currently indicated by setting single bits in the 32-bit Modes 175 Field. However, more complex encoding may be used in the future. 177 3.2.2. Registry Management 179 Because the "OWAMP-Modes" are based on only 32 bit positions with 180 each position conveying a unique feature, and because TWAMP is an 181 IETF protocol, these registries must be updated only by "IETF 182 Consensus" as specified in [RFC5226] (an RFC that documents registry 183 use and is approved by the IESG). 185 3.2.3. Experimental Numbers 187 No experimental bit positions are currently assigned in the Modes 188 Registry, as indicated in the initial contents below. 190 3.2.4. OWAMP-Modes Initial Contents 192 OWAMP-Control connection establishment follows the procedure defined 193 in section 3.1 of [RFC4656]. 195 In the OWAMP-Modes registry, assignments are straightforward on the 196 basis of bit positions, and there are no references to values - this 197 is a difference from the comparable TWAMP registry (and a topic for 198 improvement in the TWAMP-Modes registry). 200 An Extension of the OWAMP-Modes is proposed in [I-D.ietf-ippm-ipsec]. 201 With this extension, the complete set of OWAMP Mode bit positions are 202 as follows (including one reserved bit position): 204 OWAMP-Modes Registry 206 Bit 207 Posit. Description Reference/Explanation 208 0 Unauthenticated RFC4656, Section 3.1 209 1 Authenticated RFC4656, Section 3.1 210 2 Encrypted RFC4656, Section 3.1 211 3 Reserved bit position (3) 212 4 IKEv2-derived Shared RFC_TBD and this memo 213 Secret Key new bit position (4) 214 5-31 Unassigned 216 In the original OWAMP and TWAMP Modes field, setting bit position 0, 217 1 or 2 indicated the security mode of the Control protocol, and the 218 Test protocol inherited the same mode (see section 4 of [RFC4656]). 220 The value of the Modes Field sent by the Server in the Server- 221 Greeting message is the bit-wise OR of the modes (bit positions) that 222 it is willing to support during this session. Thus, the last four 223 bits of the Modes 32-bit Field are used. When no other features are 224 activated, the first 28 bits MUST be zero. A client conforming to 225 this extension of [RFC5357] MAY ignore the values in the first 28 226 bits of the Modes Field, or it MAY support other features that are 227 communicated in these bit positions. 229 OWAMP and TWAMP registries for Modes may grow to contain different 230 features and functions due to the inherent differences in one-way and 231 two-way measurement configurations and the metrics they measure. No 232 attempt will be made to coordinate them unnecessarily, except the 233 Reserved bit position 3 above. This is available for assignment if a 234 mixed security mode [RFC5618] is defined for OWAMP, and would allow 235 alignment with the comparable TWAMP feature. 237 4. Security Considerations 239 As this memo simply requests creation of a registry, it presents no 240 new security or privacy issues for the Internet. 242 The security considerations that apply to any active measurement of 243 live networks are relevant here as well. See [RFC4656] and 244 [RFC5357]. 246 Privacy considerations for measurement systems, particularly when 247 Internet users participate in the tests in some way, are described in 248 [I-D.ietf-lmap-framework]. 250 5. Acknowledgements 252 The author would like to thank Kostas Pentikousis, Nalini Elkins, and 253 Mike Ackermann for insightful reviews and comments. 255 6. References 257 6.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 263 Zekauskas, "A One-way Active Measurement Protocol 264 (OWAMP)", RFC 4656, September 2006. 266 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 267 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 268 May 2008. 270 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 271 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 272 RFC 5357, October 2008. 274 6.2. Informative References 276 [I-D.ietf-ippm-ipsec] 277 Pentikousis, K., Zhang, E., and Y. Cui, "IKEv2-derived 278 Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec-10 279 (work in progress), May 2015. 281 [I-D.ietf-lmap-framework] 282 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 283 Aitken, P., and A. Akhter, "A framework for Large-Scale 284 Measurement of Broadband Performance (LMAP)", draft-ietf- 285 lmap-framework-14 (work in progress), April 2015. 287 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 288 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 289 August 2009. 291 Author's Address 293 Al Morton 294 AT&T Labs 295 200 Laurel Avenue South 296 Middletown,, NJ 07748 297 USA 299 Phone: +1 732 420 1571 300 Fax: +1 732 368 1192 301 Email: acmorton@att.com 302 URI: http://home.comcast.net/~acmacm/