/
On the Need for MAC Deferral During Fast RetrainRelated to 802.3az D3. On the Need for MAC Deferral During Fast RetrainRelated to 802.3az D3.

On the Need for MAC Deferral During Fast RetrainRelated to 802.3az D3. - PDF document

luanne-stotts
luanne-stotts . @luanne-stotts
Follow
372 views
Uploaded On 2015-10-12

On the Need for MAC Deferral During Fast RetrainRelated to 802.3az D3. - PPT Presentation

IEEE 8023az Task Force July 2010 Supporters ID: 158066

IEEE 802.3az Task Force July

Share:

Link:

Embed:

Download Presentation from below link

Download Pdf The PPT/PDF document "On the Need for MAC Deferral During Fast..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

On the Need for MAC Deferral During Fast RetrainRelated to 802.3az D3.1 Comments 83, 96, 97David Chalupsky, Ilango GangaIntel Corp.IEEE 802.3az Task ForceJuly 2010 IEEE 802.3az Task Force, July 2010 Supporters•Sanjay Kasturia, Teranetics•Hugh Barrass –Cisco•Matt Brown, Brad Booth –Applied Micro•Kamal Dalmia, Paul Langner –Aquantia IEEE 802.3az Task Force, July 2010 Problem Statement •Either IDLE or Local Fault may be generated by the PHY to the MAC during fast retrain.•Neither option is desirable and has system-level impact. IEEE 802.3az Task Force, July 2010 Option A –Sending IDLE to the MAC In this case the MAC will be unaware that the link is not available.•Pros: Avoids a Link Down indication to the host system.•Cons: Allows 30msec of data from the MAC to be dropped silently.•Violates the spirit of our 802.3az objective:–“No frames in transit shall be dropped or corrupted during the transition to and from the lower level of power consumption”•Contrary to the Data Center Bridging efforts in 802.1 which seekto provide a “lossless Ethernet”fabric for datacenter applications.•Makes 10GBASE-T a lossyprotocol and will negate the DCB efforts.Applications which use DCB expect a lossless infrastructure (i.e., FCoE). Users of such applications will not accept 10GBASE-T with this behavior. IEEE 802.3az Task Force, July 2010 Option B –Signal Local Fault to MAC during Fast RetrainThe MAC will interpret Local Fault as a link down condition. Pros: Stops packet Txfrom the MAC and minimizes data loss.Cons:•Creates a “link flap”condition as seen by higher layers.•Typical response in a NIC application:–MAC sees Local Fault as link down–Controller interrupts driver–driver signals link down to operating system–Logs Link Down occurrence in system event log –Initiates fail over to redundant link –Possible workaround by filtering out link down indication for 30msec…but that delays fail over for legitimate link loss cases.•Switching application will also see Local Fault as link loss with undesirable consequences, such as initiating failover. IEEE 802.3az Task Force, July 2010 Suggested Remedy•Implement new message to RS which will indicate CARRIER_DETECT to MAC for Txdeferral.•Link Unavailable.27;䝐•Utilize “MAC Transmit Deferral During Fast Retrain”as baseline solution.–brown_01_0710.pdf IEEE 802.3az Task Force, July 2010 Buffering Considerations Link Unavailable.27;䘠provides additional information to switch indicating temporary condition, allowing informed response.–May choose to drop time-sensitive data (video/voice)–May choose to buffer and pause no-drop traffic classes (i.e., FCoE)–May choose only to pause best effort classes (TCP)IDLEgives no indication of link condition. –Data hopelessly lost.Local Faultgives no indication that the condition is temporary.–May prematurely begin discarding data, initiating fail over, etc.–May choose to wait 30msec, in which case buffering impact is similar to having Link Unavailable�.39;璂•Delays failover for legitimate link loss case