idnits 2.17.1 draft-morton-ippm-owamp-registry-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 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 (April 6, 2015) is 3301 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-09 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) April 6, 2015 5 Intended status: Standards Track 6 Expires: October 8, 2015 8 Registries for the One-Way Active Measurement Protocol - OWAMP 9 draft-morton-ippm-owamp-registry-00 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 October 8, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 (WG in the IETF. The Two-Way Active Measurement Protocol, 96 TWAMP [RFC5357] is an extension of OWAMP. The TWAMP specification 97 gathered wide review as it approached completion, and the by-products 98 were several recommendations for new features in TWAMP. As a result, 99 a registry of new features was established for TWAMP. However, there 100 were no new features proposed for OMAMP until recently. 102 This memo establishes the needed registries for OWAMP, and updates 103 [RFC4656]. 105 2. Purpose and Scope 107 The purpose and scope of this memo is to describe and request the 108 establishment of registries for future OWAMP [RFC4656] extensions. 109 IANA already administrates the "Two-way Active Measurement Protocol 110 (TWAMP) Parameters", and this request follows a similar form (with 111 one exception identified below). 113 This memo also provides the initial contents for the registries. 115 3. IANA Considerations for OWAMP Control Registries 117 OWAMP-Control protocol coordinates the measurement capability. All 118 OWAMP Control messages follow specifications defined in section 3 of 119 [RFC4656]. 121 3.1. Control Command Number Registry 123 IANA is requested to create a OWAMP-Control Command Number registry. 125 OMAMP-Control Commands follow specifications defined in section 3 of 126 [RFC4656]. 128 3.1.1. Registry Specification 130 OMAMP-Control Commands Numbers are specified in the first octet of 131 OWAMP Control-Client command messages consistent with section 3 of 132 [RFC4656]. There are a maximum of 256 command numbers. 134 3.1.2. Registry Management 136 Because the "OWAMP-Control Command Numbers" registry can contain only 137 256 values, and because OWAMP is an IETF protocol, these registries 138 must be updated only by "IETF Consensus" as specified in [RFC5226] 139 (an RFC that documents registry use and is approved by the IESG). 141 3.1.3. Experimental Numbers 143 One experimental value is currently assigned in the Command Numbers 144 Registry, as indicated in the initial contents below. 146 3.1.4. OWAMP-Control Command Numbers Initial Contents 148 OWAMP-Control Commands follows the procedure defined in section 3.5 149 of [RFC4656] (and in the remainder of section 3). 151 The complete set of OWAMP-Control Command Numbers are as follows 152 (including one reserved bit position): 154 OWAMP-Control Command Numbers Registry 156 Value Description Semantics Definition 157 0 Reserved 158 1 Request-Session RFC 4656, Section 3.5 159 2 Start-Sessions RFC 4656, Section 3.7 160 3 Stop-Sessions RFC 4656, Section 3.8 161 4 Fetch-Sessions RFC 4656, Section 3.9 162 5 Experimentation This Memo 163 6-255 Unassigned 165 3.2. OWAMP-Modes 167 IANA is requested to create a OWAMP-Modes registry. 169 3.2.1. Registry Specification 171 OWAMP-Modes are specified in OWAMP Server Greeting messages and Set- 172 up Response messages consistent with section 3.1 of [RFC4656]. Modes 173 are currently indicated by setting single bits in the 32-bit Modes 174 Field. However, more complex encoding may be used in the future. 176 3.2.2. Registry Management 178 Because the "OWAMP-Modes" are based on only 32 bit positions with 179 each position conveying a unique feature, and because TWAMP is an 180 IETF protocol, these registries must be updated only by "IETF 181 Consensus" as specified in [RFC5226] (an RFC that documents registry 182 use and is approved by the IESG). 184 3.2.3. Experimental Numbers 186 No experimental bit positions are currently assigned in the Modes 187 Registry, as indicated in the initial contents below. 189 3.2.4. OWAMP-Modes Initial Contents 191 OWAMP-Control connection establishment follows the procedure defined 192 in section 3.1 of [RFC4656]. 194 In the OWAMP-Modes registry, assignments are straightforward on the 195 basis of bit positions, and there are no references to values - this 196 is a difference from the comparable TWAMP registry (and a topic for 197 improvement in the TWAMP-Modes registry). 199 An Extension of the OWAMP-Modes is proposed in [I-D.ietf-ippm-ipsec]. 200 With this extension, the complete set of OWAMP Mode bit positions are 201 as follows (including one reserved bit position): 203 OWAMP-Modes Registry 205 Bit 206 Posit. Description Reference/Explanation 207 0 Unauthenticated RFC4656, Section 3.1 208 1 Authenticated RFC4656, Section 3.1 209 2 Encrypted RFC4656, Section 3.1 210 3 Reserved bit position (3) 211 4 IPsec mode new bit position (4) 212 5-31 Unassigned 214 In the original OWAMP and TWAMP Modes field, setting bit position 0, 215 1 or 2 indicated the security mode of the Control protocol, and the 216 Test protocol inherited the same mode (see section 4 of [RFC4656]). 218 The value of the Modes Field sent by the Server in the Server- 219 Greeting message is the bit-wise OR of the modes (bit positions) that 220 it is willing to support during this session. Thus, the last four 221 bits of the Modes 32-bit Field are used. When no other features are 222 activated, the first 28 bits MUST be zero. A client conforming to 223 this extension of [RFC5357] MAY ignore the values in the first 28 224 bits of the Modes Field, or it MAY support other features that are 225 communicated in these bit positions. 227 4. Security Considerations 229 The security considerations that apply to any active measurement of 230 live networks are relevant here as well. See [RFC4656] and 231 [RFC5357]. 233 5. Acknowledgements 235 The author would like to thank for helpful review and 236 comments. 238 6. References 240 6.1. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 246 Zekauskas, "A One-way Active Measurement Protocol 247 (OWAMP)", RFC 4656, September 2006. 249 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 250 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 251 May 2008. 253 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 254 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 255 RFC 5357, October 2008. 257 6.2. Informative References 259 [I-D.ietf-ippm-ipsec] 260 Pentikousis, K., Zhang, E., and Y. Cui, "IKEv2-based 261 Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec-09 262 (work in progress), February 2015. 264 Author's Address 265 Al Morton 266 AT&T Labs 267 200 Laurel Avenue South 268 Middletown,, NJ 07748 269 USA 271 Phone: +1 732 420 1571 272 Fax: +1 732 368 1192 273 Email: acmorton@att.com 274 URI: http://home.comcast.net/~acmacm/