[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.
>