Network Working Group G. Mirsky Internet-Draft M. Perumal Updates: 5357 (if approved) Ericsson Intended status: Standards Track R. Foote Expires: December 16, 2016 Nokia June 14, 2016 UDP Port Allocation for the Receiver Port in Two-Way Active Measurement Protocol (TWAMP) draft-mirsky-ippm-twamp-refl-registered-port-00 Abstract This document arguments and requests allocation of the UDP port number from the User Ports range for a Reflector in Two-Way Active Measurement Protocol (TWAMP) . This document, if accepted, will be an update to the TWAMP Test protocol specified in RFC 5357. 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 http://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 December 16, 2016. Copyright Notice Copyright (c) 2016 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 (http://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 Mirsky, et al. Expires December 16, 2016 [Page 1] Internet-Draft Registered Receiver Port Number in TWAMP June 2016 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 3. Impact to TWAMP-Control Protocol . . . . . . . . . . . . . . 3 4. Impact to TWAMP-Test Protocol . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction One particular compelling vision of the Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is widespread deployment of open servers that would make IP Performance Metrics (IPPM) measurements a commonplace. This is complemented by the proliferation of the Internet of Things (IoT) devices, such as sensors, and the need for obtaining IPPM measurements from those devices by the service provider. IoT devices are often constrained by limited processing power and memory and benefit from TWAMP Light, as defined in Appendix I [RFC5357]. TWAMP Light provides a simple solution for devices to act as test points in the network, by avoiding the need for the TWAMP-Control protocol [RFC5357]. In the absence of TWAP-Control, a registered (default) UDP port that can be used as the Receiver Port for TWAMP- Test will simplify configuration and management of the TWAMP-Light test sessions. This document requests allocation of the UDP port number from the User Port range [RFC6335] as Receiver Port for TWAMP-Test. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Mirsky, et al. Expires December 16, 2016 [Page 2] Internet-Draft Registered Receiver Port Number in TWAMP June 2016 3. Impact to TWAMP-Control Protocol Section 3.5 [RFC5357] describes in details the process of negotiating value of the Receiver Port. The Control-Client, acting on behalf of the Session-Sender, proposes the port number from the Dynamic Port range [RFC6335]: "The Receiver Port is the desired UDP port to which TWAMP-Test packets will be sent by the Session-Sender (the port where the Session-Reflector is asked to receive test packets). The Receiver Port is also the UDP port from which TWAMP-Test packets will be sent by the Session-Reflector (the Session-Reflector will use the same UDP port to send and receive packets)." But the proposed Receiver Port may be not available, e.g. in use by other test session or another application. In this case: "... the Server at the Session-Reflector MAY suggest an alternate and available port for this session in the Port field. The Session- Sender either accepts the alternate port, or composes a new Session- Request message with suitable parameters. Otherwise, the Server uses the Accept field to convey other forms of session rejection or failure to the Control Client and MUST NOT suggest an alternate port; in this case, the Port field MUST be set to zero." Use of the allocated TWAMP Receiver Port number TBA is backward compatible as the described above process will be followed by the Control Client and the Server. At the same time, use of the UDP port number allocated from the User Port range [RFC6335] will help to avoid the situation when the Server finds the proposed port being already in use. 4. Impact to TWAMP-Test Protocol TWAMP-Test may be used to measure IP performance metrics in an Equal Cost Multipath (ECMP) environment. Though algorithms to balance IP flows among available paths had not been standardized, the most common is the Five-tuple that uses destination IP address, source IP address, protocol type, destination port number, and source port number. To attempt to monitor different paths in ECMP network is sufficient to variate only one of five parameters, e.g. the source port number. Thus, there will be no negative impact on ability to have concurrent TWAMP test sessions between the same test points to monitor different paths in the ECMP network when using the allocated UDP port number as the Receiver Port. An additional benefit is the impact of the allocation of the TWAMP Receiver Port from the User Port Range [RFC6335] is for TWAMP Light Mirsky, et al. Expires December 16, 2016 [Page 3] Internet-Draft Registered Receiver Port Number in TWAMP June 2016 mode of the TWAMP-Test. The allocated UDP port number (TBA ) may be used as default value for the Receiver Port to simplify configuration and management of the TWAMP-Light test sessions. 5. IANA Considerations The Service Name and Transport Protocol Port Number Registry defined in [RFC6335]. IANA is requested to reserve a new UDP port number from the User Port range as follows: +----------+----------------+-----------------------+---------------+ | UDP Port | Description | Semantics Definition | Reference | | Number | | | | +----------+----------------+-----------------------+---------------+ | TBA | TWAMP Receiver | Section 4 | This document | | | Port | | | +----------+----------------+-----------------------+---------------+ Table 1: TWAMP Receiver Port 6. Security Considerations The registered UDP port as the Receiver Port for TWAMP-Test does not introduce new security vulnerabilities that are not already addressed by the security features of TWAMP in [RFC5357] and its updates. A Session-Reflector that does not want to use UDP port TBA can provide, through the Server acting on its behalf, a different port in the Port field of the Accept-Session message. 7. Acknowledgements TBD 8. 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, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . Mirsky, et al. Expires December 16, 2016 [Page 4] Internet-Draft Registered Receiver Port Number in TWAMP June 2016 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . Authors' Addresses Greg Mirsky Ericsson Email: gregory.mirsky@ericsson.com Muthu Arul Mozhi Perumal Ericsson Ferns Icon Doddanekundi, Mahadevapura Bangalore, Karnataka 560037 India Email: p.muthu.arul.mozhi@ericsson.com Richard Foote Nokia Email: footer.foote@nokia.com Mirsky, et al. Expires December 16, 2016 [Page 5]