Re: Deconstructing OAM&P
Rich,
I believe that we are agreeing that the only level of operations and performance information
that is needed to be leveraged from the SONET/SDH system is the "Path". You do not want to use
inband traffic bandwidth to send and receive physical layer operations and maintenance
information. All of these things would not be as available without leveraging the SONET/SDH
technology. Otherwise a lot of time will be spent developing new technology might delay the
deployment of 10GbE and the additional development money will have to recovered in a higher
cost interface. Since 10GbE is going to be full duplex, the fiber or wavelength that will
transmitting, will not be same as the one that is receiving. There will be two separate "links"
between any two interface ports.
Thank you,
Roy Bynum
MCI WorldCom
Rich Taborek wrote:
> Roy Bynum wrote:
>
> > Rich,
> >
> > You are correct. A full duplex Ethernet link is equivalent to the "Path" of a
> > SONET/SDH system. I believe that the new term that is being used in the OIF is
> > "Trail".
> >
> > The "Line" definition within SONET/SDH are equivalent to the WAN service link. This
> > would apply to situations where 10GbE would be put on active DWDM systems or commercial
> > SONET/SDH services. The active "Line" information processing would be done on the
> > active DWDM or the SONET/SDH systems, not the 10GbE port or switch. The "Section"
> > function of SONET/SDH deals with physical fiber connections between DWDM or SONET/SDH
> > Line Terminating Equipment or regenerators. Again, this would not be part of the 10GbE
> > port or switch processing.
>
> This sounds appropriate. Is a fair comparison that a "Line" is equivalent to a SONET/SDH
> transport which could encapsulate the payload of 10 Gbps Ethernet packets? Is the equipment
> that commonly converts from one to the other commonly referred to as a bridge or router? If
> it is, then this discussion is not relevant to the objectives of the HSSG. The HSSG is
> focused on developing 10 Gbps Ethernet optical links to meet distance requirements of up to
> 40 km.
>
> > Within the SONET/SDH path OAM functionality are several items that would be useful.
> > There is a path origination identification that is equivalent to the port MAC address
> > of an Ethernet port. This allows service providers to identify the customer link
> > without looking at any of the data. It will also allow MAC to MAC link identification
> > without impacting any of the active traffic. There is a bit interleave parity function
> > that can be used to detect bit errors that also does not impact active traffic. There
> > is a status indicator that can send some status and link received error performance
> > information back to the far end port, again without impacting the active traffic.
> > There are other items that might also be used. I will be going over these at the Kent
> > meeting.
>
> In native Ethernet, there is no need to burden the Physical layer with overhead
> specifically allocated to configuration or link maintenance and its corresponding
> management. In general, packet-based LANs and SAN, including Ethernet, meet configuration,
> link maintenance and general management requirements by architecting measurement facilities
> at the Physical layer and Transport facilities at the MAC layer and above. The reasoning
> being that since optical links typically operate at link BER rates much lower than 10^-12,
> and that configuration and other management requests are very infrequent. Therefore, a more
> efficient use of link bandwidth is to send management packets on an as-needed rather than
> synchronous basis. This to me "impacts the active traffic" much less than does a
> synchronous management transport alternative.
>
> Please also note the protocol danger of reporting management (e.g. error) information using
> the same link which recognized the error, and of using the same and loop/ring protocol to
> do so. Much confusion can result, akin to playing the game of "telephone", with a group of
> folks arranged in a circle whispering in each others ear. The original transmitter of the
> message will typically and eventually receive a corrupted copy of the original message.
> This problem is solved by employing switched architectures and higher level-based protocol
> transports.
>