IPv6 Benchmarking Methodology Ciprian Popoviciu, Ahmed Hamza, Gunter Van de Velde, Diego Dugatkin IETF 69, July 22nd 2007 Chicago draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Agenda Overview Last Call Review Last Call Discussion Next steps draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 “A document providing guidance in the area of IPv6 benchmarking would be welcome to organizations (including the US federal agencies mandated to deploy IPv6 on their backbone networks) attempting to understand why and how network device IPv6 performance must be tested. A document that attempts to define which areas need to considered and which describes how to test/benchmark these areas may be well received.” Bill Cerveny Overview: Complements RFC2544 by: Adds benchmarking methodology recommendations that address specific aspects of IPv6 protocol architecture Provide an updated list of benchmarks based on the experience gained with applying the RFC2544 recommendations to IPv4 Adds information related to SONET as a popular media type not mentioned by RFC2544 Went through several rounds of review within BMWG and v6ops WG draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Overview (cont.) Interest Expressed by networking and test tool vendors There is at least one implementation of the draft in a benchmarking suite Used in benchmarking related to the OMB and DoD IPv6 mandates. Timeline Voted WG Working Item during the Montreal IETF 66th meeting Currently in final WG Last Call until August 10 draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Last Call Review Official Last Call reviews by: Scott Bradner Bill Cerveny Rajiv Asati All points made by the reviewers are addressed in version: draft-ietf-bmwg-ipv6-meth-02 The reviews and the resolution of points made are documented at: http://home.comcast.net/%7Eacmacm/BMWG/IPv6-meth-comment-resolution.pdf draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Last Call Discussion Additional comments and recommendations from: David Newman (Topic: maximum throughput) Dan Romascanu, Scott Bradner, David Newman (Topic: jumbo frames) Timmons Player, Curtis Villamizar, Scott Bradner (Topic: back-to-back test) Scott Bradner (Topic: throughput definition) All these topics were addressed as documented in: http://home.comcast.net/%7Eacmacm/BMWG/IPv6-meth-comment-resolution.pdf draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Last Call Discussion (Cont.) One open item: David Newman (Topic: SONET minimum frame size and accounting for the presence of signature fields in packets) Proposed resolution: Ethernet: 64, 128, 256, 512, 1024, 1280, 1518 bytes SONET: 47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, 4096 bytes Include a note for the following topics: - 47 was chosen as the limit case - how to select a minimum frame size to include the signature field draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 IPv6 Benchmarking test suite: Vendor implementation RFC2544/IPv6 Benchmark Suite, based on this IETF draft Traffic Setup enhancements IP/IPv6 dual stack Test Setup Additions IPv6 Extension Headers IP/IPv6 traffic ratio   draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 IPv6 Benchmarking test suite: Vendor implementation Signature = PatternSignature (4B) + PacketGroupID + SequenceNumber + DataIntegrityChecksum + TimeStamp (default 20 B) = (variable size 2 to 12, default 4B) + (optional field, fixed-size = 4 Bytes) + (optional field, fixed-size = 2 Bytes) + (optional field, fixed-size = 6 Bytes) In general, the default “signature” Ixia uses is 20 bytes.  However, the term "signature" is overloaded as it includes several components. Ingeneral, at the BMWG the term refers with to the sum of various elements that create identification overhead and the corresponding integrity checksums, etc. Those 20 bytes of identification overhead (aka "signature") are the addition of the Ixia Pattern Signature (“pattern-signature”) itself (variable but usually 4 bytes), and the other 16 bytes coming from the sum of PacketGroupID (4 bytes), Sequence Number (4 bytes), Data Integrity Checksum (2 bytes), and Time Stamp (6 bytes). However, the pattern-signature and associated fields described above can be manipulated and selected individually, e.g., using IxExplorer, to have smaller total overheads. For example, the “signature” can be set to only include the pattern-signature, omitting the other fields mentioned above.  Also, Ixia allows the pattern-signature to be manipulated as a variable field that can be set as small as desired (in bytes), and can be user-defined to include any specific pattern (it is not forced to be the default Ixia pattern).  Using less than 2 bytes is not recommended because the likelyhood of having that same pattern randomly appear intermingled within the traffic increases as the size of the pattern decreases.  As general rule-of-thumb, 4-bytes is the recommended size and the default value. The maximum length for the (user defined) Ixia Pattern-Signature itself is 12 bytes, thus the maximum total overhead is 28 bytes (12 + 16), which includes the other fields of PacketGroupID (4 bytes), Sequence Number (4 bytes), Data Integrity Checksum (2 bytes), and Time Stamp (6 bytes). -- -- -- -- 1) What is the length of the Signature that IXIA uses in packets for testing purposes (to check delay, out of order, etc)? Typically is 20 bytes, but is variable and can be flexibly adjusted by the user between 2 bytes and 28 bytes.  Less than 4 bytes is typically not recommended. 2) Is the length of the field variable or fixed? Variable. 3) Since the concept was introduced, did IXIA change the lenght of the field? Yes.  It was made variable to accommodate different signature sizes and provide flexibility to select all, some or none of the possible identification and integrity fields that collectively result in the overhead generally called “signature” (which includes the pattern-signature itself, too). 4) Are there any plans to increase the field? No; not beyond the current pattern-signature itself (“Ixia Signature”) plus the additional 16 bytes for the other identification and integrity fields (PacketGroupID, Sequence Number, Data Integrity Checksum, Time Stamp) mentioned above.   One of the topics discussed at IETF65 was related to the IANA section for this draft and some discussion is included in the BMWG proceedings. There was a bias for obtaining a dedicated IPv6 range in similar fashion as what is available for IPv4 benchmarking through rfc2544. draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Next Steps The draft is currently in a final Last Call for the period: 14 July 2007 through 10 August 2007 Next Steps: Reach agreement on the last open item: minimum frame size for SONET and inclusion of signature field Include any additional comments Deliver the final version of the draft for publication draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 THANK YOU! draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 Document Goals: Address a very acute and growing need for recommendations on evaluating network element performance for IPv6 deployments A complement rather than a replacement of RFC2544 in accordance with BMWG strategy Provide the additional, IPv6 specific guidelines to IP benchmarking while indicating the aspects of RFC2544 that are IP version independent Maintain the structure and spirit of RFC2544. draft-ietf-bmwg-ipv6-meth-02

draft-ietf-bmwg-ipv6-meth-02 WG Feedback: List of Reviewers from BMWG and V6OPS WGs : Scott Bradner, Al Morton, Fred Baker, Pekka Savola, Brian Carpenter, Tim Chown, Benoit Lourdelet, Daniel Roesen, Jerry Perser, William Cerveny , Athanassios Liakopoulos, Rajiv Papneja, Sven Lanckmans, Silvija Dry, Aamer Akhter, Rajiv Asati, David Newman, Jim Mcquaid, Timmons Player, Miles McCredie, Curtis Villamizar. IPv6 and Test tools experts reviewed and provided valuable feedback off the BMWG alias. Thank you to all reviewers! draft-ietf-bmwg-ipv6-meth-02