Re: [802.3ae] Re: FW: Apparent Inconsistencies in P802.3ae D3.1
Dan, Mike,
As Norival indicated below the latching function of the Section, Line, Path and
FarEndPath Status attributes, and the related clear Actions, were eliminated
during D3.1 comment resolution and will not appear in D3.2. The reason for this
change was a concern similar to Item 2 below, in our case that multiple
management entities could be accessing the same status attribute simultaneously.
This could cause problems with a status bit being set, one management entity
accessing the attribute and then clearing it through the associated action and
then the second entity access the attribute and seeing all the bits clear.
Instead the group decided that the status attributes should provide a read of
the current Section, Line and Path status and the various counters would provide
the indication of how often an error condition was occurring. This approach is
similar to the one we have used in the past for status indications such as
aMediaAvailable with its associated counter, aLoseMediaCounter.
Regards,
David Law
"Norival Figueira" <norival@xxxxxxxxxxxxxxxxxx> on 06/08/2001 19:10:42
Sent by: "Norival Figueira" <norival@xxxxxxxxxxxxxxxxxx>
To: Dan Romascanu <dromasca@xxxxxxxxx>
cc: "HSSG_reflector , heard@xxxxxxxxx (David Law/GB/3Com)
Subject: [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>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.
>>