--- 1/draft-ietf-ippm-port-twamp-test-02.txt 2018-11-04 19:13:08.488985074 -0800 +++ 2/draft-ietf-ippm-port-twamp-test-03.txt 2018-11-04 19:13:08.512985650 -0800 @@ -1,80 +1,82 @@ Network Working Group A. Morton, Ed. Internet-Draft AT&T Labs Updates: 4656 and 5357 (if approved) G. Mirsky, Ed. Intended status: Standards Track ZTE Corp. -Expires: April 7, 2019 October 4, 2018 +Expires: May 8, 2019 November 4, 2018 OWAMP and TWAMP Well-Known Port Assignments - draft-ietf-ippm-port-twamp-test-02 + draft-ietf-ippm-port-twamp-test-03 Abstract This memo explains the motivation and describes the re-assignment of well-known ports for the OWAMP and TWAMP protocols for control and measurement, and clarifies the meaning and composition of these standards track protocol names for the industry. The memo updates RFC 4656 and RFC 5357, in terms of the UDP well- - known port assignments. + known port assignments, and clarifies the complete OWAMP and TWAMP + protocol composition for the industry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 7, 2019. + This Internet-Draft will expire on May 8, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Definitions and Background . . . . . . . . . . . . . . . . . 3 5. New Well-Known Ports . . . . . . . . . . . . . . . . . . . . 4 - 5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 5 + 5.1. Impact on TWAMP-Control Protocol . . . . . . . . . . . . 4 5.2. Impact on OWAMP-Control Protocol . . . . . . . . . . . . 5 - 5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 6 + 5.3. Impact on OWAMP/TWAMP-Test Protocols . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 10.2. Informative References . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 11.2. Informative References . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The IETF IP Performance Metrics (IPPM) working group first developed the One-Way Active Measurement Protocol, OWAMP, specified in [RFC4656]. Further protocol development to support testing resulted in the Two-Way Active Measurement Protocol, TWAMP, specified in [RFC5357]. Both OWAMP and TWAMP require the implementation of a control and mode @@ -100,21 +101,21 @@ 3. Scope The scope of this memo is to re-allocate well-known ports for the UDP Test protocols that compose necessary parts of their respective standards track protocols, OWAMP and TWAMP, along with clarifications of the complete protocol composition for the industry. The memo updates [RFC4656] and [RFC5357], in terms of the UDP well- known port assignments. -4. Definitions +4. Definitions and Background This section defines key terms and clarifies the required composition of the OWAMP and TWAMP standards-track protocols. OWAMP-Control is the protocol defined in Section 3 of [RFC4656]. OWAMP-Test is the protocol defined in Section 4 of [RFC4656]. OWAMP is described in a direct quote from Section 1.1 of[RFC4656]: "OWAMP actually consists of two inter-related protocols: OWAMP- @@ -135,66 +136,52 @@ implementation of both TWAMP-Control and TWAMP-Test are REQUIRED for standards-track TWAMP specified in [RFC5357]. TWAMP Light is an idea described in Informative Appendix I of [RFC5357], and includes an un-specified control protocol (possibly communicating through non-standard means) combined with the TWAMP- Test protocol. The TWAMP Light idea was relegated to the Appendix because it failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation, and no specifications for mandatory-to-implement security - features), as described in the references below: - - o Lars Eggert's Area Director review [LarsAD], where he pointed out - that having two variants of TWAMP, Light and Complete (called - standards track TWAMP here), required a protocol mechanism to - negotiate which variant will be used. See Lars' comment on Sec - 5.2. The working group consensus was to place the TWAMP Light - description in Appendix I, and to refer to the Appendix only as an - "incremental path to adopting TWAMP, by implementing the TWAMP- - Test protocol first". - - o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was - an incomplete specification because the key required for - authenticated and encrypted modes depended on the TWAMP-Control - Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS]. - Additional requirement statements were added in the Appendix to - address Tim's DISCUSS Ballot (see the last three paragraphs of - Appendix I in [RFC5357]). + features), as described in Appendix A of this memo, which cites + [LarsAD] and [TimDISCUSS] . Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose re-allocated assignment is requested here). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test - (implementing the security requirements, for example), otherwise the - Appendix would be one sentence long (equivocating TWAMP Light with - TWAMP-Test only). + (implementing the security requirements, for example), otherwise + Appendix I of [RFC5357] would be one sentence long (equivocating + TWAMP Light with TWAMP-Test only). 5. New Well-Known Ports Originally, both TCP and UDP well-known ports were assigned to the control protocols that are essential components of standards track OWAMP and TWAMP. Since OWAMP-Control and TWAMP-Control require TCP transport, they cannot make use of the UDP ports which were originally assigned. However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP transport. This memo requests re-assignment of the UDP well-known port from the Control protocol to the Test protocol (see the IANA Considerations Section 7). Use of this UDP port is OPTIONAL in standards-track OWAMP and TWAMP. It may simplify some operations to have a well- known port available for the Test protocols, or for future specifications involving TWAMP-Test to use this port as a default - port. + port. For example, [TR-390] is a specification for testing at the + customer edge of IP networks, and whose implememntations should + benefit. 5.1. Impact on TWAMP-Control Protocol Section 3.5 [RFC5357] describes the detailed process of negotiating the Receiver Port number, on which the TWAMP Session-Reflector will send and receive TWAMP-Test packets. The Control-Client, acting on behalf of the Session-Sender, proposes the Receiver port number from the Dynamic Port range [RFC6335]: "The Receiver Port is the desired UDP port to which TWAMP-Test @@ -300,36 +288,74 @@ | owamp-test | 861 | udp | OWAMP-Test | [RFCXXXX] | | | | | | | | twamp- | 862 | tcp | TWAMP-Control | [RFC5357] | | control | | | | | | twamp-test | 862 | udp | TWAMP-Test Receiver | [RFCXXXX] | | | | | Port | | +------------+-------+---------+----------------------+-------------+ Table 1 Re-allocated OWAMP and TWAMP Ports - where RFCXXXX is this memo when published. + where RFCXXXX is this memo when published. The Assignee and Contact + should information be updated as follows: + + Assignee: IESG + + Contact: IETF Chair 8. Contributors Richard Foote and Luis M. Contreras made notable contributions on this topic. -9. Acknowledgements +9. Appendix A + + This informative Appendix provides the Background on the decision to + move the TWAMP Light idea to an informative Appendix in [RFC5357]. + + The TWAMP Light idea was relegated to the Appendix because it failed + to meet the requirements for IETF protocols (there are no + specifications for negotiating this form of operation, and no + specifications for mandatory-to-implement security features), as + described in the references below: + + o Lars Eggert's Area Director review [LarsAD], where he pointed out + that having two variants of TWAMP, Light and Complete (called + standards track TWAMP here), required a protocol mechanism to + negotiate which variant will be used. See Lars' comment on Sec + 5.2. The working group consensus was to place the TWAMP Light + description in Appendix I, and to refer to the Appendix only as an + "incremental path to adopting TWAMP, by implementing the TWAMP- + Test protocol first". + + o Tim Polk's DISCUSS Ballot, which points out that TWAMP Light was + an incomplete specification because the key required for + authenticated and encrypted modes depended on the TWAMP-Control + Session key. See Tim's DISCUSS on 2008-07-16 [TimDISCUSS]. + Additional requirement statements were added in the Appendix to + address Tim's DISCUSS Ballot (see the last three paragraphs of + Appendix I in [RFC5357]). + + Since the idea of TWAMP Light clearly includes the TWAMP-Test + protocol and other undefined facilities, Appendix I of [RFC5357] + simply describes ideas of how TWAMP-Test might be used ouside of the + context of Standards-Track TWAMP. + +10. Acknowledgements The authors thank the IPPM working group for their rapid review; also Muthu Arul Mozhi Perumal and Luay Jalil for their participation and suggestions. -10. References +11. References -10.1. Normative References +11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, . @@ -349,29 +375,34 @@ [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . -10.2. Informative References +11.2. Informative References [LarsAD] "https://mailarchive.ietf.org/arch/msg/ippm/ LzcTPYhPhWhbb5-ncR046XKpnzo", April 2008. [TimDISCUSS] "https://datatracker.ietf.org/doc/rfc5357/history/", July 2008. + [TR-390] "TR-390 Performance Measurement from IP Edge to Custom er + Equipment using TWAMP Light, Issue: 1", May 2017, + . + Authors' Addresses Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192