Wan Phy Requirements
Since we have a consensus that we are going to have a seperate WAN PHY, I thought
I'll start a new thread where we can discuss the WAN PHY requirements.
First do we really need a seperate framing structure for 10GbE WAN. Why do we not
just use the OC192, as is. I don't think the penalty is too much. And we can
certainly cut down time-to-market and costs. For instance, we can use the same
Framer and concentrator chips that are currently being used/ developed for OC192. I
think the main reason why we were leaning towards a "lite" framer was to make it
acceptable to the LAN people.
Roy, I do not underastand some of your points below. The SPE will be allowed to
float. Are you just fixing the H1,H2 bytes. I think they have to vary, plus we need
H3 also. Plus these bytes are in the Line overhead, so we anyway end up using the
section overhead (or at least a portion of it). Granted we might not need the DCC
and K1,K2 but how much overhead do they really consume?
I also do not understand what you mean when you say " the service providers will
insert their own active information in the line/section overheads". The line and
section overhead functionality would be embedded in the ethernet frame or higher
layer protocols. Are you thinking about splitting the ethernet frame and putting
the non-user data in the line/section overhead.
I have other comments about the BER, jitter etc. requirements. But first, we need
to clarify the framing..
Thanks
Rohit Mittal
Microlinear, Engineering
> Ed, Howard, all,
>
> Now that a consensus has been achieved on developing separate PHYs for LAN and
> WAN, I can perhaps propose a specific implementation of the WAN compatible PHY.
> I would recommend that the WAN compatible PHY be based on the OC192C signaling
> standard. The majority of the sync frame will contain only static default
> information, with the following exceptions:
>
> H1, H2 - line overhead payload offset bytes - static data, numeric, "522"
>
> J1 - path overhead trace byte - a static programmable 64 or 16 byte message
> string to identify the 802.3 path ( I prefer 16 bytes because this would make it
> compatible with SDH also.)
>
> B3 - path bit interleaved parity - dynamically calculated, binary
>
> C2 - path signal label - static TBD
>
> G1 - path status byte - dynamically determined from reverse link status
> information
>
> H4 in first STS overhead - path indicator byte - static "0"
>
> H4 in remaining STS overheads - path indicator byte - static "concatenation
> indicator"
>
> For those that may not be familiar with the above byte label definitions, please
> see pages 8 and 9 of the SONET tutorial at
> http://www.tek.com/Measurement/App_Notes/SONET/ . The majority of this tutorial
> would not apply to 10GbE, but it will help some to understand the implementation
> practices of common services carriers.
>
> As you can see. I am recommending that only the path overhead have any active
> processing associated with it. At that, only 2 bytes have fully dynamic
> information; B3 and G1. J1 will have data that will be repeating every 16 sync
> frames to be able to communicate the trace message. Since service provider
> transmission systems would insert their own active information in the line and
> section overheads, it would not be necessary for 10GbE to supply active line or
> path information, only place holder bytes in the sync frame. I have gotten more
> than one vendor to unofficially agree that this would work as path trib to
> either a "lite" LTE, or an active DWDM transponder. I have also gotten MCIW's
> internal network management standards people to agree to this type of
> implementation.
>
> I hope that this will help to speed the development of the WAN compatible PHY.
> SNMP MIB entries will need to be defined for the path overhead information. The
> PHY to MAC management link will have to be defined to provide for the PHY
> management and SNMP registration.
>
> Thank you,
> Roy Bynum
> MCI WorldCom
>