draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt   draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08.txt 
Benchmarking Working Group M. Georgescu Benchmarking Working Group M. Georgescu
Internet Draft L. Pislaru Internet Draft L. Pislaru
Intended status: Informational RCS&RDS Intended status: Informational RCS&RDS
Expires: October 2017 G. Lencse Expires: December 2017 G. Lencse
Szechenyi Istvan University Szechenyi Istvan University
April 29, 2017 June 12, 2017
Benchmarking Methodology for IPv6 Transition Technologies Benchmarking Methodology for IPv6 Transition Technologies
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07.txt draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08.txt
Abstract Abstract
There are benchmarking methodologies addressing the performance of There are benchmarking methodologies addressing the performance of
network interconnect devices that are IPv4- or IPv6-capable, but the network interconnect devices that are IPv4- or IPv6-capable, but the
IPv6 transition technologies are outside of their scope. This IPv6 transition technologies are outside of their scope. This
document provides complementary guidelines for evaluating the document provides complementary guidelines for evaluating the
performance of IPv6 transition technologies. More specifically, performance of IPv6 transition technologies. More specifically,
this document targets IPv6 transition technologies that employ this document targets IPv6 transition technologies that employ
encapsulation or translation mechanisms, as dual-stack nodes can be encapsulation or translation mechanisms, as dual-stack nodes can be
skipping to change at page 1, line 46 skipping to change at page 1, line 46
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 29, 2016. This Internet-Draft will expire on December 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 34 skipping to change at page 5, line 34
number} tuples, which are stored in a state table. For ease of number} tuples, which are stored in a state table. For ease of
reference, the IPv6 transition technologies which employ stateful reference, the IPv6 transition technologies which employ stateful
mapping algorithms will be called stateful IPv6 transition mapping algorithms will be called stateful IPv6 transition
technologies. The efficiency with which the state table is managed technologies. The efficiency with which the state table is managed
can be an important performance indicator for these technologies. can be an important performance indicator for these technologies.
Hence, for the stateful IPv6 transition technologies additional Hence, for the stateful IPv6 transition technologies additional
benchmarking tests are RECOMMENDED. benchmarking tests are RECOMMENDED.
Table 1 contains the generic categories as well as associations with Table 1 contains the generic categories as well as associations with
some of the IPv6 transition technologies proposed in the IETF. some of the IPv6 transition technologies proposed in the IETF.
Please note that the list is not exhaustive.
Table 1. IPv6 Transition Technologies Categories Table 1. IPv6 Transition Technologies Categories
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| | Generic category | IPv6 Transition Technology | | | Generic category | IPv6 Transition Technology |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 1 | Dual-stack | Dual IP Layer Operations [RFC4213] | | 1 | Dual-stack | Dual IP Layer Operations [RFC4213] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] | | 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |
+---+--------------------+------------------------------------+ +---+--------------------+------------------------------------+
| 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] | | 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
skipping to change at page 7, line 19 skipping to change at page 7, line 19
For the test setups presented in this memo, dynamic routing SHOULD For the test setups presented in this memo, dynamic routing SHOULD
be employed. However, the presence of routing and management frames be employed. However, the presence of routing and management frames
can represent unwanted background data that can affect the can represent unwanted background data that can affect the
benchmarking result. To that end, the procedures defined in benchmarking result. To that end, the procedures defined in
[RFC2544] (Sections 11.2 and 11.3) related to routing and management [RFC2544] (Sections 11.2 and 11.3) related to routing and management
frames SHOULD be used here. Moreover, the "Trial description" frames SHOULD be used here. Moreover, the "Trial description"
recommendations presented in [RFC2544] (Section 23) are also valid recommendations presented in [RFC2544] (Section 23) are also valid
for this memo. for this memo.
In terms of route setup, the recommendations of [RFC2544] Section 13 In terms of route setup, the recommendations of [RFC2544] Section 13
are valid for this document assuming that an IPv6 version of the are valid for this document assuming that IPv6 capable routing
routing packets shown in appendix C.2.6.2 is used. protocols are used..
4.1. Single translation Transition Technologies 4.1. Single translation Transition Technologies
For the evaluation of Single translation transition technologies, a For the evaluation of Single translation transition technologies, a
single DUT setup (see Figure 1) SHOULD be used. The DUT is single DUT setup (see Figure 1) SHOULD be used. The DUT is
responsible for translating the IPvX packets into IPvY packets. In responsible for translating the IPvX packets into IPvY packets. In
this context, the tester device SHOULD be configured to support both this context, the tester device SHOULD be configured to support both
IPvX and IPvY. IPvX and IPvY.
+--------------------+ +--------------------+
skipping to change at page 9, line 26 skipping to change at page 9, line 26
overhead is the RECOMMENDED value for the physical interfaces as overhead is the RECOMMENDED value for the physical interfaces as
well as virtual ones. well as virtual ones.
5.1.1. Frame Sizes to Be Used over Ethernet 5.1.1. Frame Sizes to Be Used over Ethernet
Based on the recommendations of [RFC5180], the following frame sizes Based on the recommendations of [RFC5180], the following frame sizes
SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links: SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links:
64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and 64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192 and
9216. 9216.
For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC]
standard can be consulted.
Note: for single translation transition technologies (e.g. NAT64) in Note: for single translation transition technologies (e.g. NAT64) in
the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be the IPv6 -> IPv4 translation direction, 64 byte frames SHOULD be
replaced by 84 byte frames. This would allow the frames to be replaced by 84 byte frames. This would allow the frames to be
transported over media such as the ones described by the IEEE 802.1Q transported over media such as the ones described by the IEEE 802.1Q
standard. Moreover, this would also allow the implementation of a standard. Moreover, this would also allow the implementation of a
frame identifier in the UDP data. frame identifier in the UDP data.
The theoretical maximum frame rates considering an example of frame The theoretical maximum frame rates considering an example of frame
overhead are presented in Appendix A. overhead are presented in Appendix A.
skipping to change at page 25, line 48 skipping to change at page 25, line 48
2.pdf 2.pdf
[Lencse1] Lencse, G., Georgescu, M. and Y. Kadobayashi, [Lencse1] Lencse, G., Georgescu, M. and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", unpublished, "Benchmarking Methodology for DNS64 Servers", unpublished,
revised version is available: revised version is available:
http://www.hit.bme.hu/~lencse/publications/ECC-2017-B-M- http://www.hit.bme.hu/~lencse/publications/ECC-2017-B-M-
DNS64-revised.pdf DNS64-revised.pdf
[Lencse2] Lencse, G., Bakai, D, "Design and Implementation of a Test [Lencse2] Lencse, G., Bakai, D, "Design and Implementation of a Test
Program for Benchmarking DNS64 Servers", IEICE Program for Benchmarking DNS64 Servers", IEICE
Transactions on Communications, to be published (vol. Transactions on Communications, vol. E100-B, no. 6. pp.
E100-B, no. 6. pp. -, June 2017.), advance publication is 948-954, (June 2017), freely available from:
available: http://doi.org/10.1587/transcom.2016EBN0007 http://doi.org/10.1587/transcom.2016EBN0007
revised version is freely available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfpp-revised.pdf
[Lencse3] http://www.hit.bme.hu/~lencse/dns64perfppc/ [Lencse3] http://www.hit.bme.hu/~lencse/dns64perfppc/
[Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the [Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the
Caching Performance of DNS64 Servers", unpublished, review Caching Performance of DNS64 Servers", unpublished, review
version is available: version is available:
http://www.hit.bme.hu/~lencse/publications/IEICE-2016- http://www.hit.bme.hu/~lencse/publications/IEICE-2016-
dns64perfppc-for-review.pdf dns64perfppc-for-review.pdf
[IEEE802.1AC-2016] IEEE Standard, "802.1AC-2016 - IEEE Standard for
Local and metropolitan area networks -- Media Access
Control (MAC) Service Definition", 2016, available:
https://standards.ieee.org/findstds/standard/802.1AC-
2016.html
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Youki Kadobayashi and Hiroaki The authors would like to thank Youki Kadobayashi and Hiroaki
Hazeyama for their constant feedback and support. The thanks should Hazeyama for their constant feedback and support. The thanks should
be extended to the NECOMA project members for their continuous be extended to the NECOMA project members for their continuous
support. The thank you list should also include Emanuel Popa, Ionut support. The thank you list should also include Emanuel Popa, Ionut
Spirlea and the RCS&RDS IP/MPLS Backbone Team for their support and Spirlea and the RCS&RDS IP/MPLS Backbone Team for their support and
insights. We would also like to thank Scott Bradner for the useful insights. We would also like to thank Scott Bradner for the useful
suggestions. We also note that portions of text from Scott's suggestions. We also note that portions of text from Scott's
documents were used in this memo (e.g. Latency section). A big thank documents were used in this memo (e.g. Latency section). A big thank
 End of changes. 9 change blocks. 
12 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/