|
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 -----
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)
--
|