data center bridging consortium · data center bridging consortium 802.1qaz dcb exchange protocol...

Data Center Bridging Consortium

802.1Qaz DCB Exchange ProtocolTest Suite

Version 1.9

Technical Document

Last Updated: April 10, 2012

Data Center Bridging Consortium HTTP://WWW.IOL.UNH.EDU/CONSORTIUMS/DCB InterOperability Laboratory 121 Technology Drive, Suite 2University of New Hampshire Durham, NH 03824

Phone: +1-603-862-0701

© 2012 University of New Hampshire InterOperability Laboratory

http://www.iol.unh.edu/consortiums/dcb

Table of Contents

Table of Contents...........................................................................................................................2

Modification Record......................................................................................................................3

Acknowledgments..........................................................................................................................4

Introduction....................................................................................................................................5

References.......................................................................................................................................7

Test Setup.......................................................................................................................................8

Group 1: ETS Configuration and Recommendation Capability...............................................9

TEST #38.1.1: TRANSMISSION OF A WELL FORMED ETS CONFIGURATION TLV.............................10TEST #38.1.2: TRANSMISSION OF A WELL FORMED ETS RECOMMENDATION TLV.........................11TEST #38.1.3: VALIDATION OF THE ETS CONFIGURATION TLV WILLING BIT................................12TEST #38.1.4: GRACEFULLY IGNORE MALFORMED ETS RECOMMENDATION TLV..........................14

Group 2: Priority-based Flow Control Capability...................................................................16

TEST #38.2.1: TRANSMISSION OF A WELL FORMED PRIORITY-BASED FLOW CONTROL TLV............17TEST #38.2.2: VALIDATION OF THE PRIORITY-BASED FLOW CONTROL TLV WILLING BIT...............18TEST #38.2.3: CORRECT SETTING OF REMOTE WILLING.................................................................20TEST #38.2.4: GRACEFULLY IGNORE MALFORMED PRIORITY-BASED FLOW CONTROL TLV.............21

Group 3: Application Priority Capability.................................................................................22

TEST #38.3.1: TRANSMISSION OF A WELL FORMED APPLICATION PRIORITY TLV...........................23TEST #38.3.2: GRACEFULLY IGNORE MALFORMED APPLICATION PRIORITY TLV............................24TEST #38.3.3: TRANSMISSION OF FCOE SUPPORT TLV................................................................25TEST #38.3.4: TRANSMISSION OF ISCSI SUPPORT TLV................................................................26

Group 4: Congestion Notification Capability...........................................................................27

TEST #38.4.1: TRANSMISSION OF A WELL FORMED CONGESTION NOTIFICATION TLV.....................28TEST #38.4.2: GRACEFULLY IGNORE MALFORMED CONGESTION NOTIFICATION TLV......................29

Group 5: System Configuration.................................................................................................30

TEST #38.5.1: DCBX ENABLED BY DEFAULT...............................................................................31TEST #38.5.2: MULTIPLE LLDP NEIGHBORS................................................................................32


Modification Record

1. January 4, 2009 Initial Version (mhagen, rzarick)2. March 5, 2010 Updated to latest standards, added Congestion NotificationTLV (mhagen)3. October 8, 2010 Updated to draft 2.0 standard (mhagen)4. December 15, 2010 Fixed ETS Configuration and PFC Configuration tests (mhagen)5. January 6, 2011 Fixed a mistake in Test 38.3.2 (mhagen)6. January 6, 2011 Rev 1.5 – cleaned up ETS Recommendation and Configurations (mhagen)7. January 7, 2011 Fixed a mistake in Test 38.1.4 (dshea)8. January 31, 2011 Fixed Malformed TLV tests (dshea)9. March 18, 2011 Updated to draft 2.4 standard (mhagen)10. April 10, 2012 Updated to the final version of the standard (mhagen)


Acknowledgments

The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite.

Mikkel Hagen University of New HampshireDaniel Shea University of New HampshireRyan Zarick University of New Hampshire


Introduction

OverviewThe University of New Hampshire’s InterOperability Laboratory (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. These tests are designed to determine if a DCB product conforms to specifications defined in IEEE Std 802.1Qaz-2011 Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks – Amendment 18: Enhanced Transmission Selection for Bandwidth Sharing Between Traffic Classes (hereafter referred to as “DCBX”). This suite of tests has been developed to help implementers evaluate the functioning of their Data Center Bridging based products. The tests do not determine if a product conforms to the IEEE standard, nor are they purely interoperability tests. Rather, they provide one method to isolate problems within a Data Center Bridging device. Successful completion of all tests contained in this suite does not guarantee that the tested device will operate with other Data Center Bridging devices. However, combined with satisfactory operation in the IOL’s semi-production environment, these tests provide a reasonable level of confidence that the Device Under Test (DUT) will function well in most multi-vendor Data Center Bridging environments.

Organization of TestsThe tests contained in this document are organized to simplify the identification of information related to a test and to facilitate in the actual testing process. Each test contains an identification section that describes the test and provides cross-reference information. The detailed section discusses the background information and specifies how the test is to be performed. Tests are grouped in order to reduce setup time in the lab environment. Each test contains the following information:

Test NumberThe Test Number associated with each test follows a simple grouping structure. Listed first is the Clause followed by the Test Group Number followed by the test's number within the group. This allows for the addition of future tests to the appropriate groups of the test suite without requiring the renumbering of the subsequent tests.

PurposeThe purpose is a short statement describing what the test attempts to achieve. The test is written at the functional level.

ReferencesThe references section lists cross-references to the IEEE standards and other documentation that might be helpful in understanding and evaluating the test and results.

Resource RequirementsThe requirements section specifies the software, hardware, and test equipment that will be needed to perform the test. The items contained in this section are special test devices, software that must reside on the DUT, or other facilities, which may not be available on all devices.

Last ModificationThis specifies the date of the last modification to this test.

DiscussionThe discussion covers the assumptions made in the design or implementation of the test as well as known limitations. Other items specific to the test are covered here.


Test SetupThe setup section describes in detail the configuration of the test environment and includes a block diagram for clarification as well as information such as the interconnection of devices, what monitoring equipment should capture, what the generation equipment should send, and any other configuration information vital to carrying out the test. Small changes in the configuration should be included in the test procedure.

ProcedureThe procedure section of the test description contains the step-by-step instructions for carrying out the test. It provides a cookbook approach to testing, and will often be interspersed with observable results.

Observable ResultsThe observable results section lists observables that can be examined by the tester to verify that the DUT is operating properly. When multiple values are possible for an observable, this section provides a short discussion on how to interpret them. Note that complete delineation between the observables in the Procedure and Observable Results is virtually impossible. As such a careful note should be made of the requirements in both sections. In certain cases, it may be necessary to modify certain steps in the Procedure section while doing the actual tests so as to be able to perform the tests. In such cases, the modifications will be noted in the summary report.

Possible ProblemsThis section provides some clues to look for if the test does not yield the expected results.

LegendFor reasons of brevity, the following abbreviation has been used in the Test Suite:

DCBX Data Center Bridging Capability ExchangeDUT Device Under TestETS Enhanced Transmission SelectionPFC Priority-based Flow ControlTS Testing Station


References

The following documents are referenced in this text:

• IEEE Std 802.1Qaz-2011 Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks – Amendment 18: Enhanced Transmission Selection for Bandwidth Sharing Between Traffic Classes

• IEEE Std 802.1Qau-2010 Virtual Bridged Local Area Networks – Amendment 13: Congestion Notification


Test Setup

The following test setup is used in this test suite:

Test Setup 1:


TestingStation

DeviceUnderTest

Monitor

Group 1: ETS Configuration and Recommendation Capability

Overview: These tests observe the behavior of the DUT during negotiation of the ETS Capability. In their entirety, these tests verify that a device properly transmits a valid, well formatted TLV and properly handles the negotiation of the capability in a variety of situations.


Test #38.1.1: Transmission of a Well Formed ETS Configuration TLV

Purpose: To verify that the DUT transmits a well formed ETS Configuration TLV.

References:[1] DCBX – Sub-annex D.2.9

Resource Requirements:• Testing Station capable of transmitting user defined DCBX frames to the DUT.• Monitor capable of capturing Ethernet traffic.

Last Modification: January 6, 2011.

Discussion: The ETS Configuration TLV is transmitted by a device to indicate to an LLDP peer how ETS should be configured including the maximum number of traffic classes supported, the assignment of priorities to traffic class group IDs and the percentage of bandwidth each traffic class group should receive.

Test Setup: Test Setup 1. Connect the Testing Station, the DUT and the Monitor as shown.

Procedure:

1. Bring the link between the TS and DUT down and then back up.2. The activity is captured and observed.

Observable Results:

On the Monitor, verify that the DUT sends a properly configured ETS Configuration TLV. Verify that the TLV type field is 127, TLV information string length field is 25, 802.1 OUI field is 00-80-C2, 802.1 subtype field is 9, Willing Bit field is 1 bit, CBS Bit field is 1 bit, reserved field is 3 bits long, Max TCs field is 3 bits, Priority Assignment Table field is 4 Octets, TC Bandwidth Table field is 8 Octets and TSA Assignment Table field is 8 octets. Verify that the number of priorities in the Priority Assignment Table field, TC Bandwidth Table field and TSA Assignment Table field does not exceed the Max TCs reported. Verify that the total percentage of bandwidth reported in the TC Bandwidth Table field is exactly 100%.

Possible Problems: None


Test #38.1.2: Transmission of a Well Formed ETS Recommendation TLV

Purpose: To verify that the DUT transmits a well formed ETS Recommendation TLV.




Discussion: The ETS Recommendation TLV is transmitted by a device to indicate to an LLDP peer a recommendation on what priorities each traffic class should be assigned, the percentage of bandwidth each traffic class should receive and the transmission selection algorithm that each traffic class should use.


Procedure:


Observable Results:

On the Monitor, verify that the DUT sends a properly configured ETS Recommendation TLV. Verify that the TLV type field is 127, TLV information string length field is 25, 802.1 OUI field is 00-80-C2, 802.1 subtype field is 10, reserved field is 8 bits long, priority assignment table field is 4 octets, TC bandwidth table field is 8 octets and TSA Assignment Table field is 8 octets. Verify that the bandwidth percentages reported in the TC bandwidth table adds up to exactly 100.



Test #38.1.3: Validation of the ETS Configuration TLV Willing Bit

Purpose: To verify that the DUT properly acts upon ETS Recommendation TLVs based on the Willing Bit.

References:[1] DCBX – Sub-annex D.2.9[2] DCBX – Sub-annex D.2.10



Discussion: The ETS Recommendation TLV is transmitted by a device to indicate to an LLDP peer a recommendation on the percentage of bandwidth each traffic class group should receive. Once the local port's Configuration Willing Bit is set to 0, it should discard and not act upon recommendations sent by the remote port.


Procedure:Part A:

1. The DUT is configured to be willing to accept ETS Configuration recommendations.2. The TS is then instructed to send ETS Recommendation and Configuration TLVs with the Willing

Bit set to 0.3. The activity is captured and observed, along with the settings of the DUT before and after the

transmission from the TS.Part B:

1. The DUT is configured to NOT be willing to accept ETS Configuration recommendations.2. The TS is then instructed to send ETS Recommendation and Configuration TLVs with the Willing


transmission from the TS.Part C:

1. The DUT is configured to NOT be willing to accept ETS Configuration recommendations.2. The TS is then instructed to send ETS Recommendation and Configuration TLVs with the Willing


transmission from the TS.Part D:

1. The DUT is configured to be willing to accept ETS Configuration recommendations.2. The TS is then instructed to send ETS Recommendation and Configuration TLVs with the Willing


transmission from the TS.

Observable Results:

Part A: Verify that the DUT configures its local parameters according to the last received ETS Recommendation TLV.Part B: Verify that the DUT does not configure its local parameters according to the last received ETS Recommendation TLV.Part C: Verify that the DUT does not configure its local parameters according to the last received ETS Recommendation TLV.


Part D: Verify that the DUT configures its local parameters according to the last received ETS Recommendation TLV.

Possible Problems: The DUT must be able to set whether it is willing or not, otherwise parts of this test may be “Not Applicable”.


Test #38.1.4: Gracefully Ignore Malformed ETS Recommendation TLV

Purpose: To verify that the DUT responds properly when it is transmitted a malformed ETS Recommendation TLV.

References:[1] DCBX – Sub-annex D.2.9[2] DCBX – Sub-annex D.2.10[3] IEEE 802.1AB – Clause 10.3.2.1



Discussion: The ETS Recommendation TLV is transmitted by a device to indicate to an LLDP peer how ETS should be configured including the maximum number of traffic classes supported, the assignment of priorities to traffic classes, the percentage of bandwidth each traffic class should receive and what transmission selection algorithm each traffic class is assigned. The TLV information string length's field is 25, and any other value would be invalid. The TC Bandwidth Table contains eight TCs with 8-bit entries. Each entry can have a value from 0-100 and any other value is invalid. The sum of the eight values should equal 100 and any other value is invalid.


Procedure:

Part A:1. The TS is instructed to transmit a properly formed ETS Recommendation TLV with the TLV

information string length set to a value less than 25.2. The TS is instructed to transmit a properly formed ETS Recommendation TLV with the TLV

information string length set to a value more than 25.3. The activity is captured and observed, along with the configurations of the DUT before and after

the test frame.Part B:

1. The TS is instructed to transmit a properly formed ETS Recommendation TLV with the TLV TC Bandwidth Table values to sum up to a number greater than 100.

2. The activity is captured and observed, along with the configurations of the DUT before and after the test frame.

Part C:1. The TS is instructed to transmit a properly formed ETS Recommendation TLV with the TLV TC

Bandwidth Table values to sum up to a number less than 100.2. The activity is captured and observed, along with the configurations of the DUT before and after

the test frame.Part D:

1. The TS is instructed to transmit a properly formed ETS Recommendation TLV with the number of priorities reported in the Priority Assignment Table field adding up to more than supported in the MAX TCs field.


Part E:1. The TS is instructed to transmit a properly formed ETS Recommendation TLV with bandwidth

assigned to more traffic classes than supported in the MAX TCs field.2. The activity is captured and observed, along with the configurations of the DUT before and after

the test frame.


Part F:1. The TS is instructed to transmit a properly formed ETS Recommendation TLV with TSAs

assigned to more traffic classes than supported in the MAX TCs field.2. The activity is captured and observed, along with the configurations of the DUT before and after

the test frame.

Observable Results:

The DUT should not act upon the improperly formed TLV frames and should not adjust any configurations in response to the TLV. In the event of the TLV information string length field being greater than 25, the DUT should ignore the additional octets and begin with the following TLV based on the information string length value of the current TLV.



Group 2: Priority-based Flow Control Capability

Overview: These tests observe the behavior of the DUT during negotiation of the Priority-based Flow Control Capability. In their entirety, these tests verify that a device properly transmits a valid, well formatted TLV and properly handles the negotiation of the capability in a variety of situations.


Test #38.2.1: Transmission of a Well Formed Priority-based Flow Control TLV

Purpose: To verify that the DUT transmits a well formed Priority-based Flow Control TLV.




Discussion: The Priority-based Flow Control TLV is transmitted by a device to indicate to an LLDP peer how many traffic classes may simultaneously support PFC, which traffic classes have PFC enabled and if MACsec bypass capability is enabled.


Procedure:


Observable Results:

On the Monitor, verify that the DUT sends a properly configured Priority-based Flow Control TLV. Verify that the TLV type field is 127, TLV information string length field is 6, 802.1 OUI field is 00-80-C2, 802.1 subtype field is 11, Willing field is 1 bit long, MBC field is 1 bit long, Reserved field is 2 bits long, PFC cap field is 4 bits long, PFC Enable field is 1 octet. Verify that the total number of priorities configured to support PFC in the PFC Enable field does not exceed the PFC cap field value.



Test #38.2.2: Validation of the Priority-based Flow Control TLV Willing Bit

Purpose: To verify that the DUT properly negotiates the operational state of the Priority-based Flow Control TLV.

References:[1] DCBX – Sub-annex D.2.11[2] DCBX – Sub-clause 38.4.2.1



Discussion: The Priority-based Flow Control TLV is transmitted by a device to indicate to an LLDP peer how many traffic classes may simultaneously support PFC and which traffic classes have PFC enabled. When the local port's willing bit is set and the remote willing bit is not set, then the local port is to change it's operational parameters to that of the remote port. If both devices are willing, then the port with the lower numerical MAC address shall take precedence.


Procedure:

Part A:1. The DUT is configured to be willing to accept Priority-based Flow Control recommendations.2. The TS is then instructed to send Priority-based Flow Control TLVs with the Willing Bit set to 0.3. The activity is captured and observed, along with the settings of the DUT before and after the


1. The DUT is configured to NOT be willing to accept Priority-based Flow Control recommendations.

2. The TS is then instructed to send Priority-based Flow Control TLVs with the Willing Bit set to 0.3. The activity is captured and observed, along with the settings of the DUT before and after the


1. The DUT is configured to NOT be willing to accept Priority-based Flow Control recommendations.

2. The TS is then instructed to send Priority-based Flow Control TLVs with the Willing Bit set to 1.3. The activity is captured and observed, along with the settings of the DUT before and after the

transmission from the TS.Part D:

1. The DUT is configured to be willing to accept Priority-based Flow Control recommendations.2. The TS is then instructed to send Priority-based Flow Control TLVs with the Willing Bit set to 1

and a MAC address numerically higher than the DUTs.3. The activity is captured and observed, along with the settings of the DUT before and after the

transmission from the TS.Part E:

1. The DUT is configured to be willing to accept Priority-based Flow Control recommendations.2. The TS is then instructed to send Priority-based Flow Control TLVs with the Willing Bit set to 1

and a MAC address numerically lower than the DUTs.3. The activity is captured and observed, along with the settings of the DUT before and after the



Observable Results:

Part A: Verify that the DUT configures its local parameters according to the last received Priority-based Flow Control TLV.Part B: Verify that the DUT does not configure its local parameters according to the last received Priority-based Flow Control TLV.Part C: Verify that the DUT does not configure its local parameters according to the last received Priority-based Flow Control TLV.Part D: Verify that the DUT does not configure its local parameters according to the last received Priority-based Flow Control TLV.Part E: Verify that the DUT configures its local parameters according to the last received Priority-based Flow Control TLV.



Test #38.2.3: Correct setting of Remote Willing

Purpose: To verify that the local port correctly sets Priority-based Flow Control Remote Willing (RW) based on the transmission from the remote port.

References:[1] DCBX – Sub-clause 38.4.2.2


Last Modification: October 8, 2010.

Discussion: The local port is required to set RW to rwNull when it has not received a Priority-based Flow Control TLV. The local port is to set RW to rwFalse when the previous frame received from the remote port contains a Priority-based Flow Control TLV with willing bit set to 0. The local port is to set RW to rwTrue when the previous frame received from the remote port contains a Priority-based Flow Control TLV with the willing bit set.


Procedure:

Part A:1. Bring the link between the TS and DUT down and then back up.2. The TS is instructed to transmit LLDP frame with no Priority-based Flow Control TLV.3. The activity is captured and observed, along with the settings of the DUT before and after the


1. Bring the link between the TS and DUT down and then back up.2. The TS is instructed to transmit LLPD frames with the willing bit of the Priority-based Flow

Control TLV set to 0.3. The activity is captured and observed, along with the settings of the DUT before and after the


1. Bring the link between the TS and DUT down and then back up.2. The TS is instructed to transmit LLPD frames with the willing bit of the Priority-based Flow

Control TLV set to 1.3. The activity is captured and observed, along with the settings of the DUT before and after the


Observable Results:

Part A: The DUT should set RW to rwNull after receiving an LLDP frame with no Priority-based Flow Control TLV.

Part B: The DUT should set RW to rwFalse after receiving an LLDP frame with the willing bit of the Priority-based Flow Control TLV set to 0.

Part C: The DUT should set RW to rwTrue after receiving an LLDP frame with the willing bit of the Priority-based Flow Control TLV set to 1.

Possible Problems: This test is Not Testable if the DUT does not make the value of RW available.


Test #38.2.4: Gracefully Ignore Malformed Priority-based Flow Control TLV

Purpose: To verify that the DUT responds properly when it is transmitted a malformed Priority-based Flow Control TLV.

References:[1] DCBX – Sub-annex D.2.11[2] IEEE 802.1AB – Clause 10.3.2.1



Discussion: The Priority-based Flow Control TLV is transmitted by a device to indicate to an LLDP peer how many traffic classes may simultaneously support PFC and which traffic classes have PFC enabled. The TLV information string length's field is 6, and any other value would be invalid. The number of priorities reported in the PFC Enable field must not exceed the number of priorities supported in the PFC Cap field.


Procedure:

1. Bring the link between the TS and DUT down and then back up.2. The TS is instructed to send properly formed LLDP frames with the TLV information string length field of

the Priority-based Flow Control TLV set to any value less than 6.3. The TS is instructed to send properly formed LLDP frames with the TLV information string length field of

the Priority-based Flow Control TLV set to any value greater than 6.4. The TS is instructed to send properly formed LLDP frames with the number of priorities enabled greater

than the reported number of priorities capable of supporting.5. The activity is captured and observed, along with the configurations of the DUT before and after the test

frame.

Observable Results:

The DUT should not act upon the improperly formed TLV frame and should not adjust any configurations in response to the TLV. In the event of the TLV information string length field being greater than 6, the DUT should ignore the additional octets and begin with the following TLV based on the information string length value of the current TLV.



Group 3: Application Priority Capability

Overview: These tests observe the behavior of the DUT during negotiation of the Application Priority Capability. In their entirety, these tests verify that a device properly transmits a valid, well formatted TLV and properly handles the negotiation of the capability in a variety of situations.


Test #38.3.1: Transmission of a Well Formed Application Priority TLV

Purpose: To verify that the DUT transmits a well formed Application Priority TLV.




Discussion: The Application Priority TLV is transmitted by a device to indicate to an LLDP peer what priority each traffic classes is using and how the traffic class is identified.


Procedure:


Observable Results:

On the Monitor, verify that the DUT sends a properly configured Application Priority TLV. Verify that the TLV type field is 127, TLV information string length field is (5 octets + 3*Number of Applications Reported), 802.1 OUI field is 00-80-C2, 802.1 subtype field is 12, Reserved field is 8 bits long and Application Priority Table field is a multiple of 3 octets. For each application reported, verify that the Priority field is 3 bits, Reserved field is 2 bits, Sel field is 3 bits and Protocol ID field is 16 bits. Additionally, verify that Sel field is a value within 1-4.



Test #38.3.2: Gracefully Ignore Malformed Application Priority TLV

Purpose: To verify that the DUT responds properly when it is transmitted a malformed Application Priority TLV.

References:[1] DCBX – Sub-annex D.2.12[2] IEEE 802.1AB – Clause 10.3.2.1



Discussion: The Application Priority TLV is transmitted by a device to indicate to an LLDP peer what priority each traffic classes is using and how the traffic class is identified. The TLV information string length's field is (5 octets + 3*Number of Applications Reported), and any other value would be invalid. The Sel field of the Application Priority table only allows values between 1-4 all other values are reserved.


Procedure:

1. Bring the link between the TS and DUT down and then back up.2. The TS is instructed to send properly formed Application TLV LLDP frames with the TLV information

string length field of the Application Priority TLV set to any value less than (5 octets + 3*Number of Applications Reported).

3. The TS is instructed to send properly formed Application TLV LLDP frames with the TLV information string length field of the Application Priority TLV set to any value greater than (5 octets + 3*Number of Applications Reported).

4. The TS is instructed to send properly formed Application TLV LLDP frames with the Sel field of an Application Priority Table entry set to 0 or 5-7.


Observable Results:

The DUT should not act upon the improperly formed TLV frame and should not adjust any configurations in response to the TLV. In the event of the TLV information string length field being greater than (5 octets + 3*Number of Applications Reported), the DUT should ignore the additional octets and begin with the following TLV based on the information string length value of the current TLV.



Test #38.3.3: Transmission of FCoE Support TLV

Purpose: To verify that the DUT transmits a well formed FCoE Support TLV.




Discussion: The Fibre Channel over Ethernet (FCoE) protocol is a popular use case for DCB. It defines two different Ethertype values for FIP (8914h) and for FCoE (8906h).


Procedure:


Observable Results:

On the Monitor, verify that the DUT sends a properly configured FCoE Application TLV. Verify that the DUT reports two Applications in the Application Priority Table. Both Sel fields shall be 1 and one shall be Ethertype 8914 and the other shall be Ethertype 8906.

Possible Problems: This test is “Not Applicable” to devices that do not support FCoE.


Test #38.3.4: Transmission of iSCSI Support TLV

Purpose: To verify that the DUT transmits a well formed iSCSI Support TLV.




Discussion: The iSCSI protocol is a popular use case for DCB. It defines a well-known TCP port number of 3260 for iSCSI traffic and a well-known TCP port number of 3205 for Internet Storage Name Service (iSNS).


Procedure:


Observable Results:

On the Monitor, verify that the DUT sends a properly configured iSCSI Application TLV. Verify that the DUT reports one application in the Application Priority Table if the DUT does not support iSNS otherwise it shall shall report two applications. For iSCSI, the DUT shall set the Sel field to 2 or 4 and the Protocol ID field shall be set to port number 3260. For iSNS, the DUT shall set the Sel field to 2 or 4 and the Protocol ID field shall be set to port number 3205.

Possible Problems: This test is “Not Applicable” to devices that do not support iSCSI.


Group 4: Congestion Notification Capability

Overview: These tests observe the behavior of the DUT during negotiation of the Congestion Notification Capability. In their entirety, these tests verify that a device properly transmits a valid, well formatted TLV and properly handles the negotiation of the capability in a variety of situations.


Test #38.4.1: Transmission of a Well Formed Congestion Notification TLV

Purpose: To verify that the DUT transmits a well formed Congestion Notification TLV.

References:[1] DCBX – Clause 38[2] CN – Sub-clause 33.5


Last Modification: March 5, 2010.

Discussion: The Congestion Notification TLV is transmitted by a device to indicate to an LLDP peer what priorities support Congestion Notification and which priorities are not in defense mode.


Procedure:


Observable Results:

On the Monitor, verify that the DUT sends a properly configured Congestion Notification TLV. Verify that the TLV type field is 127, TLV information string length field is 6, 802.1 OUI field is 00-80-C2, 802.1 subtype field is 8, Per-priority CNPV indicators field is 1 octet and Per-priority Ready indicators field is 1 octet. Verify that only one Congestion Notification TLV is sent per LLDP PDU. Verify that the DUT does not set the Per-priority CNPV indicators field to all zero.



Test #38.4.2: Gracefully Ignore Malformed Congestion Notification TLV

Purpose: To verify that the DUT responds properly when it is transmitted a malformed Congestion Notification TLV.

References:[1] DCBX – Clause 38[2] CN – Sub-clause 33.5[3] IEEE 802.1AB – Clause 10.3.2.1



Discussion: The Congestion Notification TLV is transmitted by a device to indicate to an LLDP peer what priorities support Congestion Notification and which priorities are not in defense mode. The TLV information string length's field is 6, and any other value would be invalid.


Procedure:

1. Bring the link between the TS and DUT down and then back up.2. The TS is instructed to send properly formed LLDP frames with the TLV information string length field of

the Congestion Notification TLV set to any value less than 6.3. The TS is instructed to send properly formed LLDP frames with the TLV information string length field of

the Congestion Notification TLV set to any value greater than 6.4. The activity is captured and observed, along with the configurations of the DUT before and after the test

frame.

Observable Results:

The DUT should not act upon the improperly formed TLV frame and should not adjust any configurations in response to the TLV. In the event of the TLV information string length field being greater than 6, the DUT should ignore the additional octets and begin with the following TLV based on the information string length value of the current TLV.



Group 5: System Configuration

Overview: These tests observe the behavior of the DUT during various situations not related to a specific TLV. In their entirety, these tests verify that a device properly has DCBX on by default and handles multiple neighbors properly.


Test #38.5.1: DCBX Enabled by Default

Purpose: To verify that the DUT has DCBX enabled by default. The device should also have the ability to disable DCBX in administrator configurations.

References:[1] DCBX – Sub-clause 38.4


Last Modification: October 8, 2010.

Discussion: Devices capable of any DCB feature should have DCBX enabled by default. The device should also have the option to administratively disable DCBX. Test Setup: Test Setup 1. Connect the Testing Station, the DUT and the Monitor as shown.

Procedure:Part A:

1. Restart the DUT and observe the DCBX settings.Part B:

1. Disable DCBX on the DUT.2. Instruct the TS to transmit valid DCBX frames.3. Observe the results.

Observable Results:

Part A: Verify that the DUT has DCBX enabled by default.Part B: After disabling DCBX on the DUT, the DUT should not act upon valid DCBX frame.



Test #38.5.2: Multiple LLDP Neighbors

Purpose: To verify that the DUT does not react to multiple LLDP neighbors.

References:[1] DCBX – Sub-clause 38.4



Discussion: DCBX is defined to only operate over a simple point-to-point link. If multiple neighbors are ever detected, the DUT is expected to discard and ignore all DCBX TLVs until the multi-neighbor situation is resolved. A neighbor is defined by its MAC Service Access Identifier (MSAP), which is the concatenation of a devices chassis ID and port ID. The multi-neighbor condition will be detected when the multiple peers are detected for greater than the longest TTL of any of the peers. Test Setup: Test Setup 1. Connect the Testing Station, the DUT and the Monitor as shown. The DUT has been configured to support at least one priority group.

Procedure:

1. Instruct the TS to transmit valid DCBX frames with the same chassis IDs and different port IDs.2. Instruct the TS to transmit valid DCBX frames with the different chassis IDs and same port IDs.3. Instruct the TS to transmit valid DCBX frames with different chassis IDs and different port IDs.4. The activity is captured and observed.

Observable Results:

On the Monitor, verify that the DUT does not act upon any of the DCBX frames transmitted.



data center bridging consortium · data center bridging consortium 802.1qaz dcb exchange protocol...

Documents