Re: PHY 10GbE OC192
Greg,
I think you are missing the point. We are discussing what is the minimum amount of overhead reqd. for sending 802.3 frames
over WAN. Certainly you can can wrap it into SONET frame and be done with it but do you need all the overhead of SONET.
The consensus seems to be NO.
Thanks
Rohit Mittal
Engineering, Microlinear Corp.
> Gentlemen,
> I believe that we are progressing toward a solution for LAN/MAN
> and this is the right group to do it. However the WAN issue is
> not as clear to myself. These are my comments/questions.
>
> On the WAN side, if OC192 was adopted for computability
> the natural question would be how this would be different from
> the IP/SONET activities already in progress. T1X1.5, IETF, ITU SG15
> and OIF PLL are all debating this issue and have proposals. In
> T1X1.5 there is a proposal on how to map 802.3 frames to SONET and
> draft text has been generated to appear in the next release of T1.105.2.
> To complicate matters, T1X1 & ITU are also considering digital wrappers that
> include FEC that keeps the SONET intact but could change how interpretability
> will proceed in the future (i.e.. it may not be necessary to use the SONET
> overhead
> bytes, since the digital wrapper will have enough OOB overhead for management).
> These digital wrappers include some overhead for additional management
> information.
> Currently the only FEC/SONET/SDH standard is G.975 that I am aware
> originally adopted for use in submarine cable, and is being used
> as a model for terrestrial use. G.975 uses a GF(256) RS (255,239,8) code
> with an interleaving depth of 16 bytes.
>
> For packet over SONET (POS) OIF has adopted IETF RFC 2615 and is
> working on other aspects of specification.
>
> Another comment is that most of the telecommunications community
> terminates the network management into CMISE/CMIP. Currently many adapt
> IP SMNP using CORBA so SMNP can co-exist with TL1 based equipment
> for a unified management interface to the network. It seems that
> this is working well for the WAN needs. I don't think that 802.3
> should rewrite any of the existing standards for inter operability at
> this level (even if it not a perfect solution).
>
> I summary, I think that the WAN (if it is to remain SONET based) is
> being sufficiently studied and supported through other standards groups.
> I don't see where 802.3 can help in this regard. However, if there
> is sufficient interest in developing an alternative for IP in the WAN,
> we need to carefully study and understand the existing standards and
> their gensis/requirements. If we are generating a new carrier for the
> WAN for the transport of IP only, then the bit rates and other items
> debated seem to have little relevance. The real question is what are
> the requirements, and are they being met sufficiently with today's
> technology. If not we have starting point for the generation of a
> standard that will be used.
>
> Greg
>
> Hillol Sarkar wrote:
> >
> > Howard,
> > I think we must try to merge at this cross over point.
> > We will propose a single PHY structure which can support both
> > 10GbE and OC192.
> > We can also have both PHY if that is more desirable. However
> > from cost point of view it would be better to have one.
> > Thanks.
> > Hillol Sarkar
> > Director of Marketing
> > Kendin Communications Inc.
> > http://10giga.com
> >
> > Howard Frazier wrote:
> >
> > > >From the various statements posted to this reflector over the past
> > > few months, it has become obvious to me that the LAN and WAN
> > > markets have different needs when it comes to the physical layer
> > > of a network interface. I would also say that it is apparent that
> > > the HSSG is at an impasse. I doubt very much that either the
> > > LAN devotees or the WAN devotees will be able to
> > > persuade their opposite numbers to abandon their well thought out
> > > and closely held beliefs and settle on a single Physical Layer
> > > definition that will serve both markets.
> > >
> > > Therefore, I encourage the HSSG to consider the development of
> > > two distinct PHYs for 10 Gigabit Ethernet. Let's call one the
> > > LAN PHY, and the other, the WAN PHY. Each of these specifications would be optimized for the intended application.
> > >
> > > As others have already stated, it is possible to build a relatively
> > > simple, low cost, low complexity device that will bridge these
> > > interfaces together. A layer diagram of such a device is shown in
> > > the attached PDF file.
> > >
> > > Referring to the diagram, on the left side, we have a cloud labled
> > > "LAN infrastructure". This is made up of the switches, routers,
> > > hubs, NICs, firewalls, gateways, servers, desktops, etc, etc,
> > > that communicate via Ethernet. On the right side, we have a
> > > cloud labled "WAN infrastructure". This is made up of the
> > > transponders, multiplexors, regenerators, amplifiers, etc,etc,
> > > that conform to SONET specifications.
> > >
> > > In between these two clouds, we have a bridge. In the context
> > > of 802.3 standards, this is an 802.1D bridge, but in practice,
> > > it could have more or less functionality than required by 802.1D.
> > > The primary purpose of this device is to hide all of the details
> > > of the underlying LAN and WAN PHYs from each other. The
> > > PHYs can use completely different signaling methods, they can
> > > use different physical media, they can run at different rates.
> > > They can also have different management attributes.
> > >
> > > I assert that the cost of such a device is dominated by the cost
> > > of the PMD (the optical components) associated with the
> > > WAN interface. I can't throw dollar figures around, but I can
> > > state with conviction that the sum of the costs for the LAN PMD,
> > > the LAN PHY, the LAN MAC, the Bridge, any associated memory,
> > > any associated microprocessor, the WAN MAC, and the WAN
> > > PHY, and associated management, is about 1/25th of the cost
> > > of the WAN PMD and its associated clock oscillator. That's
> > > right. Relatively speaking, the WAN optics cost about 25 times
> > > as much as the rest of the components in the box combined.
> > >
> > > That tells me that such a device will definitely not be a barrier
> > > to the use of 10 Gigabit Ethernet in the WAN, and it might even
> > > be considered an "enabler", because it can connect to the LAN
> > > infrastructure just about anywhere you wish. Of course, since
> > > I am suggesting that we specify a WAN PHY as well as a LAN
> > > PHY, it is possible to build an interface for an "Enterprise" LAN
> > > switch that provides a WAN PHY and PMD, and maybe this
> > > will happen. The "Two PHY" approach allows inovation and
> > > optimization to keep pace with technology development, and
> > > the needs of the market.
> > >
> > > It will also let us get going in the HSSG, and put some of the
> > > arguments behind us. To that end, I suggest that we:
> > >
> > > 1) Adopt an objective to specify a PHY optimized for LAN
> > > applications.
> > >
> > > 2) Adopt an objective to specify a PHY optimized for WAN applications.
> > >
> > > 3) Settle the "speed" objective by stating that the MAC/PLS
> > > interface always runs at 10.0000 Gb/s.
> > >
> > > This speed will work with either PHY. For various reasons,
> > > the WAN PHY will require at least a packet's worth of buffering
> > > in each direction. If you have to have the buffer, you might
> > > as well use it to match the 10.0000 Gb/s MAC/PLS rate to
> > > the 9.95328 baud rate on the WAN medium.
> > >
> > > 4) Agree that a pacing mechanism of some sort can be employed
> > > if necessary to throttle the MAC's transmit data rate down to a
> > > rate which is compatible with the payload rate of a WAN PHY.
> > >
> > > With a packet buffer in the PHY, this pacing mechanism can
> > > operate on a packet by packet basis.
> > >
> > > Note: If you were to design an integrated MAC and WAN PHY,
> > > you could get rid of the buffer and the pacing mechanism.
> > >
> > > 5) Agree that the two PHYs need to be individually justified in
> > > the "5 Criteria". I am not suggesting that two PHYs means two
> > > standards projects (i.e. two PARs), but I do think that we need
> > > to answer the 5 Criteria for both PHYs, so that the rest of the
> > > world understands why we are doing this. I think it will be
> > > easier to come up with words which justify the two PHYs
> > > individually than it would be to agree to one set of words that
> > > embraces both PHYs.
> > >
> > > Please give this suggestion some serious thought.
> > >
> > > Howard Frazier
> > > Cisco Systems, Inc.
> > >
> > > ------------------------------------------------------------------------
> > > Name: toophy.pdf
> > > toophy.pdf Type: Acrobat (application/pdf)
> > > Encoding: x-uuencode
> >
> > --
> > Hillol Sarkar
> > http://10giga.com
> > mailto:Hillol.Sarkar@xxxxxxxxxx
> > Tel:(408) 735-1118 Ext:202
> > Tel:(408) 806-9354 Cell