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

[802.3ae] Re: FW: Apparent Inconsistencies in P802.3ae D3.1



Dan, Mike,

There were some major changes made to aFarEndPathStatus and WIS Status
3 register from D3.0 to D3.1. Because of this, we overlooked the fact
that far end AIS-P and far end LOP-P are reported using the same
ERDI-P code and cannot be indicated separately in either aFarEndPathStatus
or WIS Status 3 register. Fixing this problem should be very easy (i.e.,
consolidation of two bits into a single one), but this requires a formal
technical comment against the upcoming draft D3.2 to be resolved in
September.

As for the need to add text to ignore ERDI-P code 110, clause 50.3.2.5
already addresses unsupported codes:

"Section, Line and Path defects and anomalies shall be detected and
processed as defined by Sections 7.3, 7.4.1 and 7.5 of ANSI T1.416-1999,
except that only those defects and anomalies listed in Table 50-4 of this
document shall be processed, with the remainder being ignored."

Note that TIM-P and UNEQ-P are not listed in Table 50-4.

I believe we eliminated all the latching functions for WIS MIB objects
going from D3.1 to D3.2. Therefore, I will leave points number 2 and 3
below to be addressed by the Clause 30 editor.

Regards,
Norival Figueira

At 01:57 AM 8/5/01 -0700, Dan Romascanu wrote:

I would like to forward to attention of the IEEE 802.3ae editors and SG members, the following message from one of the contributors to the IETF Ethernet WIS MIB effort. I hope that you will find the comments on the issues raised by this message useful.

Regards,

Dan

> -----Original Message-----
> From: C. M. Heard [mailto:heard@xxxxxxxxx]
> Sent: Friday, August 03, 2001 1:26 AM
> To: Dan Romascanu
> Subject: Apparent Inconsistencies in P802.3ae D3.1
>
>
> Dan --
>
> While preparing my comments on <draft-ietf-hubmib-wis-mib-00.txt>
> I found some apparent inconsistencies in P802.3ae D3.1, which you
> will find listed below my signature.  One of these seems fairly
> important because it concerns the implementability of a hardware
> interface.  I'm not certain what is the proper procedure to follow
> to get this information to the IEEE.  I know that in some cases it's
> customary to follow a formal liason procedure, but I don't know if
> that applies here.  Some guidance or suggestion from you would be
> greatly appreciated.  If you think it would suffice simply to forward
> this note to someone in the IEEE then please feel free to do so.
>
> Regards,
>
> Mike
>
> Issues with P802.3ae D3.1 uncovered while reviewing ETHER-WIS draft
> -------------------------------------------------------------------
>
> 1.  aFarEndPathStatus and WIS STatus Register 3 Far-End AIS
> and LOP Bits
>     are Inconsistent with the Path Status (G1) Byte Coding
> Specifications
>
>    P802.3ae D3.1 clause 30.8.1.1.25 defines three bit positions for
>    the managed object aFarEndPathStatus.  The first bit is defined
>    to indicate remote payload defects (PLM-P or LCD-P), the second
>    is defined to indicate remote AIS-P defects, and the third is
>    defined to indicate remote LOP-P defects.  Clause 45.2.2.8 defines
>    three corresponding status bits in 10G WIS Status 3 register
>    (Register 2.33), viz., 2.33.10  (Far End PLM-P/LCD-P), 2.33.9 (Far
>    End AIS-P), and 2.33.8 (Far End LOP-P).  On the other
> hand, P802.3ae
>    clause 50.3.2.1, Transmit Path Overhead Insertion, states
> that the G1
>    overhead byte (STS PAth Status) is supported and is coded according
>    to the specifications of ANSI T1.416-1999;  and clause 50.3.2.5,
>    Fault Processing, states that path defects and anomalies listed in
>    Table 504 -- including, in particular, ERDI-P -- shall be
>    detected and processed as defined by Section 7.5 of ANSI
> T1.416-1999.
>    Section 7.5 of ANSI T1.416-1999 states in turn that the setting of
>    ERDI-P in response to LOP-P and AIS-P, TIM-P or UNEQ-P, or PLM-P is
>    specified in ANSI T1.231.  Here is what ANSI T1.231-1997 says:
>
>       8.1.2.4.5.3  ERDI-P Signal
>       The ERDI-P signal is the occurrence of a "101", "110", or "010"
>       pattern in bits 5, 6, and 7 of the G1 byte in the path overhead.
>       The ERDI-P signal shall be generated within 100 ms by an STS PTE
>       upon detection of a defect(s) shown in the following:
>       1. ERDI-P signal="101" upon detection of an AIS-P or
> LOP-P defect
>       2. ERDI-P signal="110" upon detection of a TIM-P or
> UNEQ-P defect
>       3. ERDI-P signal="010" upon detection of a PLM-P defect (29)
>       Since more than one of these defects can occur
> simultaneously and
>       only one can be carried by the ERDI-P at a time, the
> defect higher
>       on the list shall have priority. Transmission of the
> ERDI-P signal
>       shall cease within 100 ms after the STS PTE no longer
> detects any
>       one of these defects. The ERDI-P signal shall
> accurately report the
>       presence or absence of any one of these defects.  The
> ERDI-P signal
>       is defined in ANSI T1.105. (30)
>
>       8.1.2.4.5.3.1  ERDI-P server defect (31)
>       The ERDI-P server defect occurs when the presence of the ERDI-P
>       signal with the G1 bits 5, 6, and 7 set to "101", or an RDI-P
>       signal (i.e., G1 bits 5, 6 and 7 set to "100" or "111") in ten
>       contiguous frames is detected. The ERDI-P server defect is
>       terminated when a signal is detected with G1 bits 5, 6, and 7
>       not set to "101", "100", or "111" in ten contiguous frames.
>
>       8.1.2.4.5.3.2  ERDI-P connectivity defect
>       The ERDI-P connectivity defect occurs when the presence of the
>       ERDI-P signal with the G1 bits 5, 6, and 7 set to "110" in ten
>       contiguous frames is detected.  The ERDI-P connectivity defect
>       is terminated when a signal is detected with G1 bits 5, 6 and 7
>       not set to "110" in ten contiguous frames.
>
>       8.1.2.4.5.3.3  ERDI-P payload defect
>       The ERDI-P payload defect occurs when the presence of the ERDI-P
>       signal with the G1 bits 5, 6, and 7 set to "010"in ten
> contiguous
>       frames is detected. The ERDI-P payload defect is terminated when
>       a signal is detected with G1 bits 5, 6 and 7 not set to "010" in
>       ten contiguous frames.
>       --
>       (29) This code is also used in ATM services to indicate
> a loss of
>       cell delineation defect (see ANSI T1.646).
>       (30) At the time of publication of this document, ITU-T
> G.707-1996
>       misstates the ERDI-P definition.
>       (31)In order to provide general compatibility with the RDI-P
>       specified in ANSI T1.231-1993, "100" and "111" are
> included in the
>       ERDI-P server defect criteria.
>
>    Clause 50.3.2.5 states that the LCD-P defect shares the same coding
>    value and reporting method as the PLM-P defect, as is the case for
>    ATM.  T1.105 further states that the encoding for no defect is 001
>    when ERDI-P is used and is 000 when RDI-P is used and that the code
>    011 is to be interpreted as no remote defect.  It can be seen,
>    then, that after taking into account all the specifications
>    incorporated by reference that that the coding and interpretation
>    of G1 bits 5, 6, and 7 is as follows:
>
>    Bit Pattern      When Transmitted           How
> Interpreted When Received
>        000               -never-                   No remote
> path defect
>        001     No locally-detected path defect     No remote
> path defect
>        010        PLM-P or LCD-P detected          Remote
> payload defect
>        011               -never-                   No remote
> path defect
>        100               -never-                   Remote
> server defect
>        101        AIS-P or LOP-P detected          Remote
> server defect
>        110               -never-                  
> Unspecified (see note)
>        111               -never-                   Remote
> server defect
>
>    Note:  110 is the encoding for a remote connectivity defect, i.e.,
>    TIM-P or UNEQ-P.  Neither of these is supported by the WIS
> (although
>    they could be, since it is possible for two WIS devices to be
>    unintentionally misconnected [TIM-P] or for a WIS device to be
>    unintentionally misconnected to an unprovisioned SONET
> port [UNEQ-P]).
>
>    One can see from this that there is no way for
> aFarEndPathStatus or for
>    10G WIS Status 3 register to separately report remote
> AIS-P and LOP-P
>    defects since both are reported to the remote end via the
> ERDI-P server
>    defect code 101.  The suggested fixes are as follows:
>
>    - re-define WIS Status 3 Register bit 2.33.9 as a reserved bit and
>    re-define WIS Status 3 Register bit 2.33.8 as a Far End AIS-P/LOP-P
>    flag;
>
>    - change the definitons of the bits of aFarEndPathStatus
> so that the
>    first bit indicates remote payload defects (PLM-P or LCD-P) and the
>    second bit indicates remote server defects (AIS-P or LOP-P).
>
>    In addition, it should be clearly specified what action should be
>    taken if the ERDI-P connectivity defect code 110 is received, even
>    if only to say that it is ignored.
>
> 2.  Status Object Clear Actions are not Atomic With Respect to Reads
>
>    aSectionStatus, aLineStatus, aPathStatus, and aFarEndPathStatus are
>    all defined to be latching, i.e., when a bit is set it remains set
>    until cleared by one of the and have corresponding clear actions
>    acClearSectionStatus, acClearLineStatus, acClearPathStatus, or
>    acClearFarEndPathStatus.  The problem is that the status objects
>    have multiple bits.  That leaves the following possibility open:
>    one of the bits in a status object is set;  the management statio
>    issues a get and then a clear action;  and while the clear
> action is
>    in flight, another bit becomes set, and then the
> underlying condition
>    clears.  The next read will not show the evidence of the transient
>    condition, which is presumably the reason for having
> latching status
>    bits.  It might be worthwhile to consider including a bit mask
>    parameter for the clear action indicating which bits are
> to be cleared.
>
> 3.  Status Objects are Mandatory but Clear Actions are Optional
>
>    aSectionStatus, aLineStatus, aPathStatus, and aFarEndPathStatus
>    are part of pWISBasic, but acClearSectionStatus, acClearLineStatus,
>    acClearPathStatus, and acClearFarEndPathStatus are part of
>    pWISOptional.  It does not seem that latching status objects would
>    be very useful without the corresponding clear objects.  It might
>    be worthwhile to consider moving the clear actions to pWISBasic.
>