Internet DRAFT - draft-pan-ippm-sdn-addr-resolv-perf
draft-pan-ippm-sdn-addr-resolv-perf
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]
