<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!--
<!ENTITY RFC4656 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4656.xml">
-->
<!ENTITY RFC5357 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">

<!ENTITY RFC6335 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="std" ipr="trust200902" docName="draft-mirsky-ippm-twamp-refl-registered-port-00" updates="5357">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<front>
	<title abbrev='Registered Receiver Port Number in TWAMP'>UDP Port Allocation for the Receiver Port in Two-Way Active Measurement Protocol (TWAMP)</title>
 
	<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
		<organization>Ericsson</organization>
		<address>
			<email>gregory.mirsky@ericsson.com</email>
		</address> 
	</author>

<author fullname="Muthu Arul Mozhi Perumal" initials="M."
        surname="Perumal">
  <organization>Ericsson</organization>
  <address>
    <postal>
      <street>Ferns Icon</street>
      <street>Doddanekundi, Mahadevapura</street>
      <city>Bangalore</city>
      <region>Karnataka</region>
      <code>560037</code>
      <country>India</country>
    </postal>
    <email> p.muthu.arul.mozhi@ericsson.com</email>
  </address>
</author>


<!--

	<author initials='M.' surname="Perumal" fullname='Muthu Arul Mozhi Perumal'>
		<organization>Ericsson</organization>
		<address>
  <postal>
    <street> Doddanekundi, Mahadevapura    </street>
    <city>Bangalore, Karnataka    </city>
    <region/>
    <code>560037   </code>
    <country>India</country>
  </postal>
  			<email>muthu.arul@gmail.com</email>
		</address> 
	</author>
-->
	<author initials='R.' surname="Foote" fullname='Richard Foote'>
		<organization>Nokia</organization>
		<address>
			<email>footer.foote@nokia.com </email>
		</address> 
	</author>

    <date day="14" month="June" year="2016" />

    <area>Transport</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

   <keyword>IPPM</keyword>
   
   <keyword>TWAMP </keyword>
	
	<abstract>
	<t>
	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.
	 </t>
	</abstract>
</front>

<middle>
  <section anchor="intro" title="Introduction">
<!--
        <t>
        The Receiver Port in the Two-Way Active Measurement Protocol (TWAMP) <xref target="RFC5357"/> 
        is the UDP port to which the Session-Sender sends TWAMP-Test packets and from which
        the Session-Reflector sends reflected TWAMP-Test packets to the Session-Sender.
        <xref target="RFC5357"/> explains  
        that the Receiver Port can be negotiated between the Control-Client at the Session-Sender
        and the Server at the Session-Reflector. But if ranges of UDP ports available for use as the Receiver Port
        at the Session-Reflector and desired by the Session-Sender are not matchig, then the test session
        would not be established.
       </t>
-->
        <t>
        One particular compelling vision of the Two-Way Active Measurement Protocol (TWAMP) <xref target="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 <xref target="RFC5357"/>.
        </t>
        <t>
        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 <xref target="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.
        </t>
        <t>
        This document requests allocation of the UDP port number from the User Port range <xref target="RFC6335"/>
        as Receiver Port for TWAMP-Test.
        </t>
 
   </section>
<!--           
     <section title="Conventions used in this document">
-->     
<!--
         <section title="Terminology">

           <t>IoT:                Internet of Things           </t>
           <t>IPPM:            IP Performance Metrics
</t>
           <t>TWAMP:        Two-Way Active Measurement Protocol
</t>
           <t>OWAMP:       One-Way Active Measurement Protocol
</t>
         </section>    
-->         
        <section title="Requirements Language">
             <t>
	  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 
	  <xref target="RFC2119"></xref>.
             </t>
          </section>
      
     <section anchor="twamp-control" title="Impact to TWAMP-Control Protocol">
          <t>
          Section 3.5 <xref target="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 <xref target="RFC6335"/>:
<list>
          <t>
         "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)."
          </t>
</list>
          </t>   

          <t>
          But the proposed Receiver Port may be not available, e.g. in use by other test session or another application.
          In this case:
          <list>
          <t>
             "... 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."
          </t>
          </list>
          </t>
          <t>
          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 <xref target="RFC6335"/> 
          will help to avoid the situation when the Server
          finds the proposed port being already in use.
          </t>
          
     </section>
           
           <section anchor="twamp-test" title="Impact to TWAMP-Test Protocol">
           <t>
           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.
           </t>
             <t>
             An additional benefit is the impact of the allocation of the TWAMP Receiver Port from the User Port Range <xref target="RFC6335"/> is for TWAMP Light 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.
             </t>
           </section>      
             

 
     <section anchor="iana-considerations" title="IANA Considerations">
     <t>
     The Service Name and Transport Protocol Port Number Registry defined in <xref target="RFC6335"/>. 
     </t>
     <t>
     IANA is requested to reserve a new UDP port number from the User Port range as follows:
     </t>

  <texttable anchor="receiver-port-alloc" title="TWAMP Receiver Port">
    <ttcol align='left'>UDP Port Number&nbsp;</ttcol>
    <ttcol align='left'>Description</ttcol>
    <ttcol align='left'>Semantics&nbsp;Definition&nbsp;</ttcol>
    <ttcol align='left'>Reference</ttcol>
    <c>TBA</c>
    <c>TWAMP Receiver&nbsp;Port&nbsp;</c>
    <c><xref target="twamp-test"/></c>
    <c>This&nbsp;document</c>
    </texttable>

     </section>
     
     <section anchor="security" title="Security Considerations">
     <t>
  
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 <xref target="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.
     </t>

     </section>
      
     
      <section title="Acknowledgements">
         <t>
<!--          
         Authors greatly appreciate thorough review and thoughtful comments by Bill Cerveny,
         Christofer Flinta and Samita Chakrabarti.
-->
         TBD
         </t>  
      </section>

  </middle>
  
    <back>
    <references title="Normative References">
     
     &RFC2119;
 
<!--
     &RFC4656;
-->     
     &RFC5357;
     
     &RFC6335;
     
   
    </references>


<!--
   <references title="Informative References">

 
    </references>

-->
 </back>
 </rfc>   
    
