Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[EFM] Re: Draft v1.0 comment #347 - OAM vs. PAUSE



Title: Re: Draft v1.0 comment #347 - OAM vs. PAUSE

Hi, Tom, All.
 
the attached file is my updated modified state diagram Fig 31B-1 for resolving the OAM and PAUSE conflict. 
                                  
 
Tom,
Thank you for your reply.
I also thought the HOL problem of OAM frame.
Thus, I totally agreed with your suggestion of a new block.
1) If the block means a new buffer for OAM, it means a definition of a new primitive for OAM as MA_data and MA_Control, I think.
2) If not, we should check the fields of OAM data(type, subtype) for distinguishing frame, and putting to the appropriate buffer. However, it is not realistic solution.
 
Please see my another message in e-mail reflector.
the attached file is about my solution.
 
slide 2 : 2)
slide 3 : 1)
 
 
----- Original Message -----
From: Tom Mathey
Sent: Friday, September 27, 2002 2:50 PM
Subject: Re: Draft v1.0 comment #347 - OAM vs. PAUSE

JAEYEON,

Thank you for your comment.  When I managd to get your file onto a computer which could open the file, your suggestion is just fine.  I tried to cover this type of solution with the text

"other methods are possible, such as no new block and modify equation for enty into block  "SEND DATA FRAME"."

By this text, I meant the exact solution you propose.  Such text was not in my comment for the simple reason that I ran out of time for submitting comments!!  Such is life.  I just made the comment submittal deadline as it was.

I suggested a new block since many implementations use a large buffer/FIFO above the mac to hold multiple frames, and a paused mac would not see such an OAM frame if data frames are ahead of it.  A new block is a hint to implementers that head of line blocking exists and the OAM frames from the mac client need to be sent to an independent buffer/fifo.

Again, thanks.

Tom

PS:  I do contract and consulting work in the Ethernet area in the San Jose, CA area if your company needs assistance.



Hi, Tom.
 
I read your comment #347 for OAM vs. PAUSE.
 
You recommend we should define another "SEND OAM FRAME"  block in Fig31B-1 for resolving the restrction use of PAUSE problem.
However, the transition from "TRANSMIT READY" to "SEND OAM FRAME" means the tranmission in normal state,
not PAUSE state.
The problem is OAM transmission under PAUSE state.
Because OAM uses the slow protocol in current draft, When the device receives the PAUSE frame, it cease the OAM transmission as well as data frame.
The reason is the slow protocol uses the MA_DATA primitive. Thus, we need the mechanism for distinguishing the OAM and DATA, if OAM track doesn't change.
 
Thus, your comment should be changed : The attatched file is my diagram.
In that diagram, there is not additional "SEND OAM FRAME" block. Because, my assumption is, if MAC receive any data primitive from MAC client, it's OAM.
It represents that OAM frame could be transmitted under PAUSE state.
 
 
 
 
 
====================================
JAEYEON SONG
 
Standards Engineer, Ph.D
Global Standard and Strategy
Telecommunication R&D Center
Samsung Electronics Co., Ltd.
Korea
 
jy_song@xxxxxxxxxxx
myhome.naver.com/gginnie/
Tel: +82-31-279-5122
FAX:+82-31-279-5130
===================================


Attachment converted: Mac 22G #1:OAM vs PAUSE.ppt (SLD3/PPT3) (000BEE4A)




-- 

OAM vs PAUSE(2).ppt