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

RE: (corrected) Re: [EFM] RE: OAM Transport Proposal




Hiroshi,

I'm a bit confused by your append here an could use an explanation.

When you say "First, Preamble handler is located in RS layer (  RS layer is strictly a part of PHY )
which has the  high-speed control  interface  ( common to MAC and above )," can you provide the reference in the existing standard to the high speed control interface that you are talking about utilizing? Do we need to change the MAC? Will this be referenced by the MIB? How?

Also, you mention that "The second, the OAMiF will be mostly like implemented by SW/FW ( that's the main reason why people want to use it ? )
the resulting latency would be unpredictable, while OAMiP detect indication will be handle by HW with predictable latency." What does "handled by HW" mean? What exactly is the system response to the reception of the preamble bits? This system response has no SW/FW component?

jonathan



| -----Original Message-----
| From: Hiroshi Suzuki [mailto:hsuzuki@xxxxxxxxx]
| Sent: Tuesday, April 23, 2002 10:09 AM
| To: Roy Bynum
| Cc: Booth, Bradley; 'mattsquire@acm.org'; 'stds-802-3-efm@ieee.org'
| Subject: Re: (corrected) Re: [EFM] RE: OAM Transport Proposal
| 
| 
| 
| 
| At 09:51 AM 4/23/2002 -0500, Roy Bynum wrote:
| 
| >Brad,
| >
| >If I understand you correctly, given that there will always 
| be additional 
| >latency translating the MDIO/MDC frames into preamble 
| information, and 
| >then send the preamble, even without a standard frame, it 
| will not provide 
| >any advantage in greater responsiveness than OAMiF.  If that 
| is the case, 
| >then there is no advantage to OAMiP under any circumstances. 
|  If that is 
| >the case, why include it even as optional?
| >
| >Thank you,
| >Roy Bynum
| 
| 
| First, Preamble handler is located in RS layer (  RS layer is 
| strictly a 
| part of PHY )
| which has the  high-speed control  interface  ( common to MAC 
| and above ).
| So the speed is not the issue.  Refer  the preamble proposals 
| presented in 
| last several meetings.
| 
| The second, the OAMiF will be mostly like implemented by SW/FW
| ( that's the main reason why people want to use it ? )
| the resulting latency would be unpredictable,
| while OAMiP detect indication will be handle by HW with 
| predictable latency.
| 
| The third, and PHY fault indication / protection  by MAC 
| control layer is
| something like SONET protection handled by IP packets
| which engineers never have used.
| 
| Hiroshi
| 
| 
| >At 06:59 AM 4/23/2002 -0700, Booth, Bradley wrote:
| >
| >>Matt,
| >>
| >>A management frame I described is that defined in Clause 22 
| as a MDIO/MDC
| >>communication.  If the preamble is filtered by the PHY, 
| then there has to be
| >>some way to pass this preamble OAM information to the 
| management entity.  In
| >>802.3, this is done via MDIO/MDC (or management frames).  A 
| management frame
| >>takes over 25 us to be passed across the MDIO/MDC 
| interface.  Unless the
| >>intention is to have the PHY handle all OAM in preamble 
| without management
| >>entity intervention, then the response to the OAM in 
| preamble will be
| >>hampered by the MDIO/MDC interface.
| >>
| >>Cheers,
| >>Brad
| >>
| >>______________________
| >>Sent from my Blackberry...
| 
|