IPPM Working Group X. Pan Internet-Draft W. Sun Intended status: Informational SJTU Expires: April 22, 2015 October 19, 2014 Address Resolution Delay Metric in Software-Defined Networking (SDN) draft-pan-ippm-sdn-addr-resolv-perf-00 Abstract 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. 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 April 22, 2015. Pan & Sun Expires April 22, 2015 [Page 1] Internet-Draft Address Resolution Delay in SDN October 2014 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Overview of Performance Metrics . . . . . . . . . . . . . . . 3 4. A Singleton Definition for ARDNFFR . . . . . . . . . . . . . 4 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5 4.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . 5 4.5. Definition . . . . . . . . . . . . . . . . . . . . . . . 5 4.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5 4.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 5 5. A Singleton Definition for ARDFFR . . . . . . . . . . . . . . 6 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 5.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . 7 5.5. Definition . . . . . . . . . . . . . . . . . . . . . . . 7 5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 5.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 7 Pan & Sun Expires April 22, 2015 [Page 2] Internet-Draft Address Resolution Delay in SDN October 2014 6. A Testing Case for Address Resolution Delay in SDN . . . . . 7 6.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 8 6.3. Metric Parameters . . . . . . . . . . . . . . . . . . . . 8 6.4. Metric Units . . . . . . . . . . . . . . . . . . . . . . 8 6.5. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 6.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 9 6.7. Methodologies . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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. 2. Conventions Used in This Document 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]. 3. Overview of Performance Metrics 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: Pan & Sun Expires April 22, 2015 [Page 3] Internet-Draft Address Resolution Delay in SDN October 2014 o Address Resolution Delay, No Forwarding Flow Registrations (ARDNFFR) - address resolution delay without flow registrations to forward ARP packets in switches. o Address Resolution Delay, Forwarding Flow Registrations (ARDFFR) - address resolution delay with flow registrations to forward ARP packets in switches. 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. 4. A Singleton Definition for ARDNFFR This section defines address resolution delay metric without forwarding flow registrations in switches in SDN. 4.1. Motivation 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: o When there are no forwarding flow registrations for ARP packets. Pan & Sun Expires April 22, 2015 [Page 4] Internet-Draft Address Resolution Delay in SDN October 2014 o When the previously existing forwarding flow registrations expire. 4.2. Metric Name ARDNFFR = Address Resolution Delay, No Forwarding Flow Registrations 4.3. Metric Parameters o H0, the ingress host ID o H1, the egress host ID o C0, the controller o T, a time when address resolution is attempted 4.4. Metric Units The value of ARDNFFR in SDN is a real number of milliseconds. 4.5. Definition 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. 4.6. Discussion 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. 4.7. Methodologies Generally, the methodology would proceed as follows: o Make sure there are no forwarding flow registrations for ARP packets in switches. Pan & Sun Expires April 22, 2015 [Page 5] Internet-Draft Address Resolution Delay in SDN October 2014 o At ingress H0, form the ARP Request packet and send out the packet at T. o H0 receives the ARP Response packet at time stamp T+dT o An estimation of ARDNFFR(dT) can be computed. 5. A Singleton Definition for ARDFFR This section defines address resolution delay metric with forwarding flow registrations in switches in SDN. 5.1. Motivation 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: o Address resolution with forwarding flow registrations in switches is the main form of address resolutions in SDN. o 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. 5.2. Metric Name ARDFFR = Address Resolution Delay, Forwarding Flow Registrations 5.3. Metric Parameters o H0, the ingress host ID o H1, the egress host ID Pan & Sun Expires April 22, 2015 [Page 6] Internet-Draft Address Resolution Delay in SDN October 2014 o C0, the controller o T, a time when address resolution is attempted 5.4. Metric Units The value of ARDFFR in SDN is a real number of milliseconds. 5.5. Definition 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. 5.6. Discussion 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. 5.7. Methodologies Generally, the methodology would proceed as follows: o Make sure the forwarding flow registrations exit in switches. o At ingress H0, form the ARP Request packet and send out the packet at T. o H0 receives the ARP Response packet at time stamp T+dT. o An estimation of ARDFFR(dT) can be computed. 6. A Testing Case for Address Resolution Delay in SDN Given the metrics of ARDNFFR and ARDFFR, we now define a testing case using those two metrics. Pan & Sun Expires April 22, 2015 [Page 7] Internet-Draft Address Resolution Delay in SDN October 2014 6.1. Metric Name Address resolution delay sample. 6.2. Motivation 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. 6.3. Metric Parameters o H0, the ingress host ID o H1, the egress host ID o C0, the controller o Ti, the time interval of switches removing the flow registrations o T0, a time o Tf, a time o Lambda, a rate in the reciprocal milliseconds 6.4. Metric Units The value of address resolution delay sample is a real number of milliseconds. 6.5. Definition 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. Pan & Sun Expires April 22, 2015 [Page 8] Internet-Draft Address Resolution Delay in SDN October 2014 6.6. Discussion 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. 6.7. Methodologies Generally, the methodology would proceed as follows: o Select the time values using the specified Possion arrival process o Set the interval time of removing flow registrations in all switches Ti o Send ARP Request from H0 to H1 at selected time values o Set ARDNFFR committed times n and ARDFFR committed time m o Then the value of address resolution delay sample is n*ARDNFFR + m*ARDFFR 7. Acknowledgements We also wish to thank 863 program of China and the National Natural Science Foundation of China (NSFC) for their support. 8. References [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. Pan & Sun Expires April 22, 2015 [Page 9] Internet-Draft Address Resolution Delay in SDN October 2014 [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. Authors' Addresses Xing Ya. Pan ShangHai JiaoTong University 800 DongChuan Road ShangHai China Phone: +86 15921940945 Email: panxingya@sjtu.edu.cn Wei Qiang. Sun ShangHai JiaoTong University 800 DongChuan Road ShangHai China Phone: +86 13801847900 Email: sunwq@sjtu.edu.cn Pan & Sun Expires April 22, 2015 [Page 10]