RE: What is 802.3ae WAN-PHY?

["David Martin" <dwmartin@xxxxxxxxxxxxxxxxxx>]

Title: RE: What is 802.3ae WAN-PHY?

Jonathan,

The J0 (Section Trace) has a proposed default value, which would be sent every frame.
Optionally, we proposed that it could be user provisioned (i.e. the user provides a value
via a mgmt interface). That value would then be sent every frame. In either case, the
value is static.

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901  
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx

========================

-----Original Message-----
From:   Jonathan Thatcher [SMTP:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent:   Monday, April 10, 2000 7:37 PM
To:     HSSG_reflector (E-mail)
Subject:        FW: What is 802.3ae WAN-PHY?

Oops. Forgot the rest of you.... jt

-----Original Message-----
From: Jonathan Thatcher
Sent: Monday, April 10, 2000 4:36 PM
To: 'David Martin'
Subject: RE: What is 802.3ae WAN-PHY?


David,
 
Thanks.
 
Yes, of course the C2 byte is static and fixed.
 
J0 is interesting. What does a "provisioned value" mean? I assumed that it meant that it potentially changes and must therefore be mapped to the management layer. Your exclusion would indicate otherwise. A little more clarification would be welcome.

 
I left B1 and B3 out because of an assumption that only the SONET framer (WAN PHY) would care about these. B3 makes sense to me since it maps across the entire path. I can't think of an equivalent for B1.

 
jonathan 
 
 -----Original Message-----
From: David Martin [mailto:dwmartin@xxxxxxxxxxxxxxxxxx]
Sent: Monday, April 10, 2000 11:49 AM
To: stds-802-3-hssg@xxxxxxxx
Subject: RE: What is 802.3ae WAN-PHY?






Jonathan,

A clarification on your reference to the contents of Norival's document.
The only dynamic OAM bytes in the proposal are B1, B3, G1 and are
calculated/updated on a 125 usec frame basis.

...Dave

David W. Martin
Nortel Networks
+1 613 765-2901  
+1 613 763-2388 (fax)
dwmartin@xxxxxxxxxxxxxxxxxx

========================

-----Original Message-----
From:   Jonathan Thatcher [SMTP:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent:   Sunday, April 09, 2000 2:33 AM
To:     stds-802-3-hssg@xxxxxxxx
Subject:        RE: What is 802.3ae WAN-PHY?




Rich-san & Osamu-san,

Yes, you are clearly catching on to my question. If I assume that there is a
FC Order Set like structure (one of many options available) to the /ODDD/
then we might have something like: /O;D1;D2;D3/. This would have D1 be an
identifier which is mapped to a specific byte of the SONET overhead (J0, C2,
or G1; see below). D2 and D3 could repeat the same data value for
redundancy.

Depending on the method used, your algorithm (((3 * 3/4)/1530) * 10 Gbps)
will have to be adjusted.

While we have been given some brief tutorials on the path and line overhead
bytes, I do not remember anything about the rules for these bytes. I don't
know if the data in the bytes is kept static unless a specific signal is
required or if one of the bytes might actually be used with a full protocol
of its own.

From the
http://grouper.ieee.org/groups/802/3/ae/public/mar00/figueira_1_0300.pdf
proposal,
we have SONET overhead bytes: B1, E1, E2, F1, D1:D12, M1, Z1, Z2 unused and
set to zero.
The following bytes are set to fixed values: A1, A2, Z0, K1, K2, S1, J1
The following bytes are calculated by the SONET framer: B1, H1, H2, H3, B3
None of these would ever have to be mapped to the /ODDD/.

As best as I can tell, the worst case is that the following 3 bytes would
have to be mapped and transmitted every 250 microseconds: J0, C2, G1

This means we need to send one of these three, roughly, every 100k-bytes (if
I didn't goof my math).

Piece of cake, right? Heck, this could even be done with jumbo frames on
steroids!

It can't be this easy. What am I missing?

jonathan





> -----Original Message-----
> From: Rich Taborek [ mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Saturday, April 08, 2000 6:41 PM
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: Re: What is 802.3ae WAN-PHY?
>
>
>
> Jonathan,
>
> It's possible, it's beyond cool, and the details and mapping
> for the data flow
> have already been proposed in various HSSG presentations as
> well as over this
> reflector. Please allow me to summarize the mapping and data
> flow below:  
>
> The delimiter and control character set (alphabet, if you
> will) proposed for the
> Reconciliation sublayer (RS) is:
>
> - Idle /I/
> - SOP /S/
> - EOP /T/
> - Error /E/
> - Data /D/
>
> We appear to have converged on four octet values for use as
> code "words" by
> noting the 36-bit XGMII, 4-lane XAUI, 4-lane WWDM, 4-lane
> SUPI, 4-lane SLP as a
> PMA interface, etc. Four octet control words also map well to proposed
> delimiters, 64B/66B transmission code, a 312.5 MHz processing
> rate for 32-bit
> information, Fibre Channel ordered-sets, XGENIE ordered-sets,
> etc. Current RS
> proposals map the five required RS control characters into
> specific code-words.
> The complete proposed code-word set based upon the five
> required RS control
> characters is:
>
> - SDDD, DDDD, TIII, DTII, DDTI, DDDT, IIII, E in any
> code-group position in the
> preceding code-words.
>
> All optional interfaces including XGMII and XAUI/XGXS, all
> sublayers including
> the PCS and PMA sublayers as well as the medium must be
> capable of somewhat
> faithfully transporting all of the above codes. I say
> somewhat, because of the
> following transmission code peculiarities:
>
> XAUI/XGXS as well as the WWDM PCS must convert /I/ to /A/K/R/
> to efficiently
> handle synchronization, skew, EMI, clock tolerance
> compensation, etc. As a
> result, XAUI transports three code-words in place of /IIII/
> and translates of
> EOP words since /I/'s are not valid 8B/10B code-groups. The
> complete set of
> code-words transported by XAUI/XGXS to support required RS codes is:
>
> - SDDD, DDDD, TKKK, DTKK, DDTK, DDDT, AAAA, KKKK, RRRR, E in
> any code-group
> position in the preceeding code-words.
> 
> 64B/66B PCS is currently proposed to transport all non error
> RS and XAUI/XGXS
> code-words transparently, but has problems with /E/ codes due
> to limitations in
> code space caused by the number of possible locations of one
> or mode /E/ codes
> in any code-word. As simple compromise is to generate 64B/66B
> /E/ "frames"
> whenever an error is detected or must be forced into the
> information stream.
> Like the replacement of /I/ by /A/K/R/, this process does not
> affect the
> contents of the information being transported between RS
> peers. I believe that
> the following list represents the information content of all
> 64B/66B frames to
> support RS codes. Note that Z may represent (I,E,A,K or R):
>
> - SDDD/DDDD, ZZZZ/DDDD, DDDD/DDDD, ZZZZ/ZZZZ, TZZZ/ZZZZ,
> DTZZ/ZZZZ, DDTZ/ZZZZ,
> DDDT/ZZZZ, DDDD/TZZZ/, DDDD/DTZZ, DDDD/DDTZ, DDDD/DDDT
>
> Now... You're asking about the mapping and data flow to
> transport OAM&P like
> information between peer PCS elements and possibly peer RS
> elements (which
> requires that the same information also be transported
> between peer PCS
> elements).
>
> In either case, additional OAM&P code-words must be defined.
> Due to two factors:
>
> 1) Simplicity of transport Logic.
> 2) Support of Fibre Channel and InfiniBand control-words;
>
> I propose, as does Mr. Osamu Ishida for XGENIE, and Mr. Rick
> Walker for 64B/66B
> in recent reflector notes, that OAM&P code-words for XGENIE
> be transported by
> code-words with the following format: ODDD. This single
> code-word minimal
> addition should have enough flexibility to meet the needs the
> link management
> needs of all envisioned protocols.
>
> I further propose that the code-word /ODDD/ be supported in a
> transmit and
> receive capacity by the RS in order that it be independent of
> the multiple
> proposed PCS sublayers as well as proposed optional XGMII and
> XGXS/XAUI
> interfaces.
>
> /ODDD/ code-words may generated at the request of Station
> Management at the RS
> during the IPG only and with a frequency no greater than 1/4
> to 1/2 the IPG
> density (1/2 may be too much, I have to think about this some
> more. 1/4 should
> definitely be OK). I believe that a 1/4 rate corresponds to
> management data
> throughput of a minimum of ((3 * 3/4)/1530) * 10 Gbps ~= 15
> Kbps or .15% of
> available link bandwidth for Ethernet OAM&P functions. These
> functions can
> include Remote Fault and Break Link signaling.
>
> The RS receiver would trap all control-words for use by
> Station Management and
> forward only MAC PLS service primitives to the MAC.
>
> /ODDD/ code-words may be inserted/removed from the IPG stream
> by Station
> Management anywhere along an Ethernet Link that Station
> Management is present. I
> believe that a "conservation of IPG bytes" rule is
> appropriate since I don't
> envision mixing OAM&P functions with clock tolerance
> compensation functions.
> Inserted OAM&P code-words must replace removed ones or ensure
> that the maximum
> frequency of OAM&P code-words is not exceeded. Deleted OAM&P
> code-words must be
> replaced by Idles or replacement OAM&P code-words.
>
> The alternative of allocating specific code-words and
> possibly multiple formats
> for OAM&P signaling would seem to complicate the
> specification of RS operation
> and PCS encodings.
>  
> I'd be honored to work with others to present complete
> details for supporting
> Ethernet OAM&P transport which is PCS, interface and LAN/WAN
> independent during
> the May interim meeting in Ottawa. If you're interested in
> helping out or simply
> endorsing this direction, please send me a private email to
> keep reflector
> traffic down.
>
> Best Regards,
> Rich
> 
> --
>
> Jonathan Thatcher wrote:
> >
> > The approach that Osamu is pursuing is interesting to me
> due the potential
> > I foresee in being able to concatenate any number of
> LAN-PHY or WAN-PHY
> > segments together in any order and still manage these with
> using existing
> > tools nearly transparently. If this is possible, it would
> be beyond cool.
> >
> > I assume the following from what I have seen thus far:
> > 1. To adopt this might not require 802.3ae to write a new set of
> > line/path/etc management primitives.
> > 2. A direct mapping would allow the "WAN" and the "LAN"
> systems to link in
> > a more direct way at, effectively, a lower level.
> > 3. It permits greater flexibility in where we might choose
> to architect the
> > SONET framer in order to optimize the solution. It might even permit
> > multiple instantiations.
> >
> > I am still curious about the details for the mapping and
> the data flow.
> >
> > jonathan
>                                     
> -------------------------------------------------------
> Richard Taborek Sr.                 Phone: 408-845-6102      
> Chief Technology Officer             Cell: 408-832-3957
> nSerial Corporation                   Fax: 408-845-6114
> 2500-5 Augustine Dr.        mailto:rtaborek@xxxxxxxxxxx
> Santa Clara, CA 95054            http://www.nSerial.com
>
>