One document matched: draft-pan-ippm-sdn-addr-resolv-perf-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!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 RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-pan-ippm-sdn-addr-resolv-perf-00" ipr="pre5378Trust200902">
<front>
<title abbrev="Address Resolution Delay in SDN">
Address Resolution Delay Metric in Software-Defined Networking (SDN)
</title>
<author initials="X.Y." surname="Pan" fullname="Xing Ya. Pan">
<organization abbrev="SJTU">
ShangHai JiaoTong University
</organization>
<address>
<postal>
<street>800 DongChuan Road</street>
<city>ShangHai</city>
<country>China</country>
</postal>
<phone>+86 15921940945</phone>
<email>panxingya@sjtu.edu.cn</email>
</address>
</author>
<author initials="W.Q." surname="Sun" fullname="Wei Qiang. Sun">
<organization abbrev="SJTU">
ShangHai JiaoTong University
</organization>
<address>
<postal>
<street>800 DongChuan Road</street>
<city>ShangHai</city>
<country>China</country>
</postal>
<phone>+86 13801847900</phone>
<email>sunwq@sjtu.edu.cn</email>
</address>
</author>
<date month="October" year="2014"></date>
<area>General</area>
<workgroup>IPPM Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>SDN</keyword>
<abstract>
<t>To send data packets from one host to another in traditional local area networks, one needs to know the MAC of destination host.
This is called the address resolution and is handled by the ARP (Address Resolution Protocol) protocol. However the ARP Request and
ARP Response mechanism in Software-Defined Networking (SDN) (RFC7149) is different from that in traditional local area networks.
In SDN, when there are no flow registrations in switches to forward ARP packets, ARP packets have to be sent to the controller first.
As resolving the ARP packets may be time consuming depending on the load on the controller and may potentially have different
implications on address resolution in SDN, characterization of this delay performance can thus help users to know the approximate
delay before the actual data forwarding process. In this document, we define performance parameters to characterize the delay metrics
of address resolution in SDN.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To send data packets from one host to another in traditional local area networks, address resolution is a very important process and is
normally handled by the Address Resolution Protocol (ARP).The source host sends out the ARP Request to get the MAC of the destination host.
However the mechanism to deal with ARP Request and ARP Response in Software-Defined Networking (SDN) is different from traditional local
area networks. In SDN, when there are no flow registrations in switches to forward ARP packets, the address resolution has to be performed
on the controller first. As resolving the ARP packets may be time consuming depending on the load and processing capability of the
controller, when the amount of data to be sent is small, the time taken in the address resolution process can be significant in relation
with the actual data sending time. Since SDN controller may potentially have different implications on address resolution, it is thus
important to characterize this delay. </t>
<t>This memo defines a set of delay metrics and test methods to obtain this delay performance.</t>
</section>
<section title="Conventions Used in This Document">
<t>The key words "MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT","SHOULD","SHOULD NOT","RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [RFC 2119].</t>
</section>
<section title="Overview of Performance Metrics">
<t>In this memo, we define two singleton metrics to characterize the delay of address resolution in two different conditions.
Then using those two singleton metrics, we introduce a testing case.</t>
<t>The two metrics are:</t>
<t><list style="symbols">
<t>Address Resolution Delay, No Forwarding Flow Registrations (ARDNFFR) - address resolution delay without flow registrations to forward ARP packets in switches.</t>
<t>Address Resolution Delay, Forwarding Flow Registrations (ARDFFR) - address resolution delay with flow registrations to forward ARP packets in switches.</t>
</list></t>
<t>The formation of this memo refers to RFC6777[RFC6777] .The delay of address resolution is conceptually similar to the unidirectional delay and
bidirectional delay in traditional local area networks. This enables us to refer to the structures and notions introduced and discussed in
the IP Performance Metrics (IPPM) Framework documents, [RFC2330] [RFC2679] [RFC2681]. The reader is assumed to be familiar with the notions
in those documents.</t>
</section>
<section title="A Singleton Definition for ARDNFFR">
<t>This section defines address resolution delay metric without forwarding flow registrations in switches in SDN.</t>
<section title="Motivation">
<t>ARDNFFR is useful for several reasons:</t>
<t>It is an important metric that characterizes the provision performance of SDN. Longer ARDNFFR will most likely incur higher
overhead for the requesting application, especially when the data sending duration is comparable to the address resolution delay.</t>
<t>The minimum value of this metric provides an indication of the delay that will likely be experienced when a packet first travel
through the networks. As the delay consists of several processes, such as link propagation delay, controller computation delay and
switch registration delay, Longer ARDNFFR may suggest problems in one or more processes. For this reason, this metric is useful for
testing and diagnostic purpose.</t>
<t>The observed variance in a sample of ARDNFFR may serve as an early indicator on the feasibility of supports on applications that
have stringent resolution delay requirements.</t>
<t>Under the following two cases, the ARP packets have to be forwarded to the controller. ARDNFFR can be used to characterize the
delay of address resolution in these two situations:</t>
<t><list style="symbols">
<t>When there are no forwarding flow registrations for ARP packets.</t>
<t>When the previously existing forwarding flow registrations expire.</t>
</list></t>
</section>
<section title="Metric Name">
<t>ARDNFFR = Address Resolution Delay, No Forwarding Flow Registrations</t>
</section>
<section title="Metric Parameters">
<t><list style="symbols">
<t>H0, the ingress host ID</t>
<t>H1, the egress host ID</t>
<t>C0, the controller </t>
<t>T, a time when address resolution is attempted</t>
</list></t>
</section>
<section title="Metric Units">
<t>The value of ARDNFFR in SDN is a real number of milliseconds.</t>
</section>
<section title="Definition">
<t>ARDNFFR from ingress host H0 to egress Host H1 at T is dT means that ingress Host H0 sends out the first bit of ARP Request
packet to egress Host H1 at wire-time T, and H0 receives the first bit of ARP Response packet from H1 at wire-time T+dT.</t>
</section>
<section title="Discussion">
<t>The following issues are likely to come up in practices:</t>
<t>One has to ensure that there are no forwarding flow registrations for ARP packets in switches.</t>
<t>The accuracy of ARDNFFR at time T depends on the clock resolution of the ingress node. Synchronization between the components is not required.</t>
<t>The accuracy of ARDNFFR at time T also depends on the process ability of the components and the load on them especially on C0.</t>
</section>
<section title="Methodologies">
<t>Generally, the methodology would proceed as follows:</t>
<t><list style="symbols">
<t>Make sure there are no forwarding flow registrations for ARP packets in switches.</t>
<t>At ingress H0, form the ARP Request packet and send out the packet at T.</t>
<t>H0 receives the ARP Response packet at time stamp T+dT</t>
<t>An estimation of ARDNFFR(dT) can be computed.</t>
</list></t>
</section>
</section>
<section title="A Singleton Definition for ARDFFR">
<t>This section defines address resolution delay metric with forwarding flow registrations in switches in SDN.</t>
<section title="Motivation">
<t>ARDFFR is useful for several reasons:</t>
<t>It is an important metric that characterizes the provision performance of SDN. Longer ARDFFR will most likely incur higher overhead
for the requesting application, especially when the data sending duration is comparable to the address resolution delay.</t>
<t>The minimum value of this metric provides an indication of the delay that will likely be experienced when a packet travel through
the networks with forwarding flow registrations in switches.</t>
<t>The observed variance in a sample of ARDFFR may serve as an early indicator on the feasibility of supports on applications that have
stringent resolution delay requirements.</t>
<t>The measurement of ARDFFR instead of ARDNFFR is motivated by the following factors:</t>
<t><list style="symbols">
<t>Address resolution with forwarding flow registrations in switches is the main form of address resolutions in SDN.</t>
<t>When the ARP cache in one host is expired, it has to do an address resolution again and the forwarding flow registrations are very likely in switches.</t>
</list></t>
</section>
<section title="Metric Name">
<t>ARDFFR = Address Resolution Delay, Forwarding Flow Registrations</t>
</section>
<section title="Metric Parameters">
<t><list style="symbols">
<t>H0, the ingress host ID</t>
<t>H1, the egress host ID</t>
<t>C0, the controller </t>
<t>T, a time when address resolution is attempted</t>
</list></t>
</section>
<section title="Metric Units">
<t>The value of ARDFFR in SDN is a real number of milliseconds.</t>
</section>
<section title="Definition">
<t>ARDFFR from ingress host H0 to egress Host H1 at T is dT means that ingress Host H0 sends out the first bit of ARP Request
packet to egress Host H1 at wire-time T, and H0 receives the first bit of ARP Response packet from H1 at wire-time T+dT.</t>
</section>
<section title="Discussion">
<t>The following issues are likely to come up in practices:</t>
<t>One has to ensure the forwarding flow registrations exist in switches.</t>
<t>The accuracy of ARDFFR at time T depends on the clock resolution of the ingress node. Synchronization between the components is not required.</t>
<t>The accuracy of ARDFFR at time T also depends on the process ability of the components and the load on them especially on switches.</t>
</section>
<section title="Methodologies">
<t>Generally, the methodology would proceed as follows:</t>
<t><list style="symbols">
<t>Make sure the forwarding flow registrations exit in switches.</t>
<t>At ingress H0, form the ARP Request packet and send out the packet at T.</t>
<t>H0 receives the ARP Response packet at time stamp T+dT.</t>
<t>An estimation of ARDFFR(dT) can be computed.</t>
</list></t>
</section>
</section>
<section title="A Testing Case for Address Resolution Delay in SDN">
<t>Given the metrics of ARDNFFR and ARDFFR, we now define a testing case using those two metrics.</t>
<section title="Metric Name">
<t>Address resolution delay sample.</t>
</section>
<section title="Motivation">
<t>Data transferring is the main form of network communications. Address resolution with and without forwarding flow
registrations may often happen in data transferring. Time consuming by them is an important part of the time consuming by data transferring.</t>
</section>
<section title="Metric Parameters">
<t><list style="symbols">
<t>H0, the ingress host ID</t>
<t>H1, the egress host ID</t>
<t>C0, the controller </t>
<t>Ti, the time interval of switches removing the flow registrations</t>
<t>T0, a time</t>
<t>Tf, a time</t>
<t>Lambda, a rate in the reciprocal milliseconds</t>
</list></t>
</section>
<section title="Metric Units">
<t>The value of address resolution delay sample is a real number of milliseconds.</t>
</section>
<section title="Definition">
<t>Given T0, Tf, and Lambda, compute a pseudo-random Poisson process beginning at or before T0, with an average arrival rate Lambda
and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected. At each of
the times in this process, we send ARP Request from H0 to H1. The switches clean the flow registrations every Ti . In each Ti the value of the
first address resolution delay is ARDNFFR and values after the first one are ARDFFRs. Then we can obtain the number of
ARDNFFR and ARDFFR committing times between T0 and Tf with time interval Ti.</t>
</section>
<section title="Discussion">
<t>The parameter lambda should be carefully chosen. If the rate is too high, since the flow registrations in all switches may not
be removed at the same time every Ti, the delay of address resolution with some flow registrations in some switches may be included
in the final result. If the rate is too low, there may be no ARP Requests in many time intervals.</t>
<t>The parameter Ti should be carefully chosen. If Ti is too large, there may be more ARDFFRs than ARDNFFRs in the final result.
If Ti is too small, there may be no ARDFFRs in the final result.</t>
</section>
<section title="Methodologies">
<t>Generally, the methodology would proceed as follows:</t>
<t><list style="symbols">
<t>Select the time values using the specified Possion arrival process</t>
<t>Set the interval time of removing flow registrations in all switches Ti</t>
<t>Send ARP Request from H0 to H1 at selected time values</t>
<t>Set ARDNFFR committed times n and ARDFFR committed time m</t>
<t>Then the value of address resolution delay sample is n*ARDNFFR + m*ARDFFR</t>
</list></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We also wish to thank 863 program of China and the National Natural Science Foundation of China (NSFC) for their support.</t>
</section>
</middle>
<back>
<references>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S ." surname="Bradner" fullname="Scott Bradner">
<organization >
Harvard University
</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC2330">
<front>
<title>Framework for IP Performance Metrics</title>
<author initials="V ." surname="Paxson"
fullname="Vern Paxson">
<organization >
Lawrence Berkeley National Laboratory
</organization>
</author>
<author initials="G ." surname="Almes"
fullname="Guy Almes">
<organization >
</organization>
</author>
<date month="May" year="1998" />
</front>
<seriesInfo name="RFC" value="2330" />
</reference>
<reference anchor="RFC2679">
<front>
<title>A One-way Delay Metric for IPPM</title>
<author initials="G ." surname="Almes"
fullname="Guy Almes">
<organization >
</organization>
</author>
<author initials="S ." surname="Kalidindi"
fullname="Guy Almes">
<organization >
</organization>
</author>
<author initials="M ." surname="J. Zekauskas"
fullname="Matthew J. Zekauskas">
<organization >
</organization>
</author>
<date month="September" year="1999" />
</front>
<seriesInfo name="RFC" value="2679" />
</reference>
<reference anchor="RFC2681">
<front>
<title>A Round-trip Delay Metric for IPPM</title>
<author initials="G ." surname="Almes"
fullname="Guy Almes">
<organization >
.
</organization>
</author>
<author initials="S ." surname="Kalidindi"
fullname="Guy Almes">
<organization >
.
</organization>
</author>
<author initials="M ." surname="J. Zekauskas"
fullname="Matthew J. Zekauskas">
<organization >
</organization>
</author>
<date month="September" year="1999" />
</front>
<seriesInfo name="RFC" value="2681" />
</reference>
<reference anchor="RFC5814">
<front>
<title>Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks</title>
<author initials="W ." surname="Sun"
fullname="Weiqiang Sun">
<organization >
Shanghai Jiao Tong University
</organization>
</author>
<author initials="G ." surname="Zhang"
fullname="Guoying Zhang">
<organization >
China Academy of Telecommunication Research, MIIT, China
</organization>
</author>
<date month="March" year="2010" />
</front>
<seriesInfo name="RFC" value="5814" />
</reference>
<reference anchor="RFC7149">
<front>
<title>Software-Defined Networking: A Perspective from within a Service Provider Environment</title>
<author initials="M ." surname="Boucadair"
fullname="Mohamed Boucadair">
<organization >
France Telecom
</organization>
</author>
<author initials="C ." surname="Jacquenet"
fullname="Christian Jacquenet">
<organization >
France Telecom
</organization>
</author>
<date month="March" year="2014" />
</front>
<seriesInfo name="RFC" value="7149" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:22:29 |