One document matched: draft-mirsky-ippm-twamp-refl-registered-port-00.txt
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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc5357>.
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,
<http://www.rfc-editor.org/info/rfc6335>.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 13:10:32 |