| IPPM Working Group | X. Pan |
| Internet-Draft | W. Sun |
| Intended status: Informational | SJTU |
| Expires: April 27, 2015 | October 24, 2014 |
Address Resolution Delay Metric in Software-Defined Networking (SDN)
draft-pan-ippm-sdn-addr-resolv-perf-00
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.
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 April 27, 2015.
Copyright (c) 2014 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
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.
This memo defines a set of delay metrics and test methods to obtain this delay performance.
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].
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.
The two metrics are:
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.
This section defines address resolution delay metric without forwarding flow registrations in switches in SDN.
ARDNFFR is useful for several reasons:
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.
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.
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.
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:
ARDNFFR = Address Resolution Delay, No Forwarding Flow Registrations
The value of ARDNFFR in SDN is a real number of milliseconds.
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.
The following issues are likely to come up in practices:
One has to ensure that there are no forwarding flow registrations for ARP packets in switches.
The accuracy of ARDNFFR at time T depends on the clock resolution of the ingress node. Synchronization between the components is not required.
The accuracy of ARDNFFR at time T also depends on the process ability of the components and the load on them especially on C0.
Generally, the methodology would proceed as follows:
This section defines address resolution delay metric with forwarding flow registrations in switches in SDN.
ARDFFR is useful for several reasons:
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.
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.
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.
The measurement of ARDFFR instead of ARDNFFR is motivated by the following factors:
ARDFFR = Address Resolution Delay, Forwarding Flow Registrations
The value of ARDFFR in SDN is a real number of milliseconds.
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.
The following issues are likely to come up in practices:
One has to ensure the forwarding flow registrations exist in switches.
The accuracy of ARDFFR at time T depends on the clock resolution of the ingress node. Synchronization between the components is not required.
The accuracy of ARDFFR at time T also depends on the process ability of the components and the load on them especially on switches.
Generally, the methodology would proceed as follows:
Given the metrics of ARDNFFR and ARDFFR, we now define a testing case using those two metrics.
Address resolution delay sample.
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.
The value of address resolution delay sample is a real number of milliseconds.
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.
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.
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.
Generally, the methodology would proceed as follows:
We also wish to thank 863 program of China and the National Natural Science Foundation of China (NSFC) for their support.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. |
| [RFC2330] | Paxson, V. and G. Almes, "Framework for IP Performance Metrics", RFC 2330, May 1998. |
| [RFC2679] | Almes, G., Kalidindi, S. and M. J. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. |
| [RFC2681] | Almes, G., Kalidindi, S. and M. J. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. |
| [RFC5814] | Sun, W. and G. Zhang, "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", RFC 5814, March 2010. |
| [RFC7149] | Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014. |