| MR # | Current Status | Subject | Date | Standard | Page | Subclause | Figure | Table | Classification | Last | First | Perceived Problem | Proposed Remedy | Rationale For Remedy | Remedy's Effect On Existing Equipment | Mar-05 Status | Jul-05 Status | Mar-06 Status | Jul-06 Status | Nov-06 Status | Jul-07 Status | Nov-07 Status | Jul-08 Status |
| 0001 | B | The definition of the NOT_USED define for the secMac variable is incorrect. | 21-Jan-05 | 802.17-2004 | 298 | 11.2.5 | Technical | Lemon | John | The definition of the NOT_USED define for the secMac variable is incorrect. | Change "zero" to "all-ones". | 0xFFFFFFFFFFFF is used as the indication of an invalid address for a secondary MAC address in Table 11.21. | None. | B | B | ||||||||
| 0002 | B | MS-MS scenario does not retain closed ring topology as described in Figure 11.29. | 24-Jan-05 | 802.17-2004 | 336 | 11.6.5.1 | Technical | Chathnath | Praveen | MS-MS scenario does not retain closed ring topology as described in Figure 11.29. Two Manual switches retain single EDGE caused by the first Manual Switch. | The Figure 11.29 and all the associated text should be updated to capture that if there is a Manual Switch present in the ring, second Manual Switch directive would be rejected. | Rationale is captured in the txt file MR_MS-MS-Rationale.txt | Should not affect the exsisting 802.17 equipment. | B | B | ||||||||
| 0003 | B | Ringlet Selection checks for reachability on wrong ringlet. | 24-Jan-05 | 802.17-2004 | 161 | 7.7.1.6.3 | 7.29 | Technical | Chathnath | Praveen | Ringlet Selection checks for reachability on wrong ringlet which would lead to traffic loss in case of a failure in ring. Reachable() function refers to the transmit direction and the topology database is computing reachability based on the receive direction. Detailed problem description is captured in MR_Reachable_PD.txt. | Remedy 1: The function Reachable() should be referring to Other(ringlet), since ringlet refers to the transmit ringlet and the topology database is computing reachability based on the receive ringlet. Remedy 2: Another solution could be changing topology database update reachability on transmit direction. Reachable(address, ringlet) should be modified as to indicate if the Topology database shows that the specified MAC address is reachable via the specified ringlet. Reachablility is determined from topoEntry[Other(ringlet)][index] where index is the index value of the station entry with topoEntry[Other(ringlet)][index] equal to address. Remedy 1 is suggested. | The Reachable() function change is simpler compared to the second option of modifying Topology state machine. | Proper ringlet selection for data frames for steering in case of a failure in ring. No side effects identified. | B | B | |||||||
| 0004 | B | The variable unreservedRate[ri] used in Fairness clause (Pages 273 & 269) should refer to the ringInfo.unreservedRate[ri]. | 24-Jan-05 | 802.17-2004 | 245 | 10.2.4 | Technical | Chathnath | Praveen | The variable unreservedRate[ri] used in Fairness clause (Pages 273 [ed: 249] & 269 [ed: 245]) should refer to the ringInfo.unreservedRate[ri]. Currently it referes to myTopoInfo.unreservedRate[ri] . | Correct the variable reference in 10.2.4 (Page 269 [ed: 245]) to ringInfo.unreservedRate[ri]. | ringInfo.unreservedRate[ri] is the variable which contains information of total unreserved bandwidth in the ringlet. More over myTopoInfo does not have a variable unreservedRate[ri]. | Should not affect the exsisting 802.17 equipment. | B | B | ||||||||
| 0005 | B | Data frames with wrong FCS are copied to the client without any verification or validation. | 25-Jan-05 | 802.17-2004 | 145 | 7.6.3.10.4 | 7.24 | Technical | Bruckman | Leon | In row 6 of table 7.24 data frames with wrong FCS (payload error) are copied to the client without any verification or validation. Since only the payload is errored, the header is presumably right, so the frames should also reach rows 8 to 16, as any other frame. | Remove row 6. Change the condition of row 7 (original 7, before removing 6) to : frame.ft == FT_DATA && !copyBadFcs && frame.fcs != Crc32(frame) | Minimum change. Note also that it is the way it was specified in draft 2.4. | If table 7.24 was implemented "as is", then a minor change in the state machine will be required. | B | B | |||||||
| 0006 | B | The ps is verified for all frames, but SCFF and MCFF frames do not have this bit. | 25-Jan-05 | 802.17-2004 | 139 | 7.6.3.8.4 | 7.22 | Technical | Bruckman | Leon | In rows 4 and 5 of table 7.22 the ps is verified for all frames, but SCFF and MCFF frames do not have this bit (no extendedControl filed in these frames) | In rows 4 and 5 in the condition cell, add the condition: frame.ft != FT_FAIRNESS | Minimum change. | Since this is an obvious error, implementors should have seen this problem and no effect is expected | R | B | |||||||
| 0007 | B | In the case of frame.ri != Other (myRi), the value of receivedTtl is not set. | 25-Jan-05 | 802.17-2004 | 270 | 10.4.8.4 | 10.13 | Technical | Bruckman | Leon | According to row 5 in table 10.13, if frame.ri != Other (myRi) the receivedTtl is not set, but in Table 10.10 row 13 the value of receivedTtl is used to set frame.ttl. Actually, in the case of frame.ri != Other (myRi) the value of receivedTtl is not set at all. | In table 10.13 row 5 add the action: receivedTtl = frame.ttl | Minimum change. | Since this is an obvious error, implementors should have seen this problem and no effect is expected | R | B | |||||||
| 0008 | B | In the box labeled crcB = HeadCrc16(.c), the c within the parenthesys should be replaced with d. | 25-Jan-05 | 802.17-2004 | 590 | E.1.3 | E.3 | Technical | Bruckman | Leon | In the box labeled crcB = HeadCrc16(.c) the c within the parenthesys should be replaced with d. | Replace the label in this box with: crcB = headCrd16(d) | Minimum change. | Since this is an obvious error, implementors should have seen this problem and no effect is expected | R | B | |||||||
| 0009 | B | Four lines are missing at the very end of page 339, so DistantStateMax does not return the correct value. | 10-Mar-05 | 802.17-2004 | 339 | 11.6.5.5 | Technical | Fan | Jason | Four lines are missing at the very end of page 339, so DistantStateMax does not return the correct value. | The four lines are: If ((hops == 1) && (ringlet == ri)) awayState = Max(awayState, tp.spanProtState[ri]); else awayState = Max(awayState, Max(tp.spanProtState[ri], tp.spanProtState[Other(ri)])); In addition, the function Max needs to be directly defined in 11.2.7, rather than referring to Clause 10. Clause 10 refers to the function Max defined in Clause 11 in 10.2.4. | These four lines ensure that awayState takes into account the protection states of all of the appropriate links on the ring, some of which would be missed otherwise. | Equipment with this change will work correctly given the protection states that this equipment sees on the ring. Equipment without this change will not work correctly. | B | B | ||||||||
| 0010 | B | Max() is not defined in Clause 11. | 10-Mar-05 | 802.17-2004 | 245 | 10.2.4 | Technical | Lemon | John | Max() is not defined in Clause 11. | Remove the reference to Max() from 10.2.4 and define the Max() routine in 10.2.3. | A definition is needed instead of the existing circular reference. | None. | R | B | ||||||||
| 0011 | B | Not all conditions are covered for declaring the operational state of the RPR interface to be down. | 10-Mar-05 | 802.17-2004 | 405 | 13.3.1.2 | Technical | Lemon | John | Not all conditions are covered for declaring the operational state of the RPR interface to be down. Both spans can be down by any reason that causes an edge. | Change the entire text of 13.2.1.2 to "The RPR interface operational state (RFC 2863) is determined as follows: * Down if either of the following conditions is true: * RPR interface administrative state (RFC 2863) is down. * Both spans are edges. * Otherwise up.". | It doesn't make sense to include PHY problems, keepalive timeout, and ringlet mismatch and not include other edge reasons. | None. | R | B | ||||||||
| 0012 | B | The values encoded into the station bandwidth ATT should not be weight normalized, and should be converted to timescale used by fairness. | 11-Mar-05 | 802.17-2004 | 311 | 11.4.2.1 | Technical | Lemon | John | The values encoded into the station bandwidth ATT should not be weight normalized, and should be converted to timescale used by fairness. | In 11.4.2.1 and 11.4.2.2, change ", normalized as per 10.1.3.8." to ". The bandwidth is reported in units of bytes per ageCoef agingIntervals, and normalized by dividing by the product of ageCoef and rateCoef to provide the numbers in the units and scale used by the fairness algorithm (see 10.1.3.8).". | The description is incomplete and at least misleading, if not completely incorrect. | Correcting the setting of this field could mislead existing equipment that may have implemented an incorrect assumption of what this field means. | R | B | ||||||||
| 0013 | B | There are a number of issues with the MIB text not conforming to the main clauses in the standard, having invalid ranges or incorrect cross references. | 11-Mar-05 | 802.17-2004 | 472 | D.6 | Technical | Jones | Peter | There are a number of issues with the MIB text not conforming to the main clauses in the standard, having invalid ranges or incorrect cross references. The quick list is as follows: rprIfProtectionSlowTimer should be range (1..10) in 100 ms units with default value=1. RprIfAtdTimer should be (1..10) in 1 seconds units with default value=1. RprIfKeepaliveTimeout should be (2..200) in 1 ms units and fix cross-reference All xxxxTimeElapsed attributes need to change from (0..899) to (0..910) otherwise a completed interval of 900 shows an invalid value. The interval definition allows an interval to be valid for 900 seconds +- 10 seconds, so the elapsed range should match this. RprTopoImageStationIfIndex needs to change to InterfaceIndexOrZero so that if you do not have the information, you can legally report 0. | A copy of the proposed new MIB text and a “diff “ against the current MIB text are separately provided. | Make sure the MIB text matches the main body clauses, and make sure that the data reported matches the MIB definitions. | None. | C | B | ||||||||
| 0014 Closed | J | There is no way to configure the MAC to not operate in a strict ordered mode for clients that do no support the strict_order parameter | 11-Mar-05 | 802.17-2004 | 60 | 6.4.1 | Technical | Holness | Marc | There is no way to configure the MAC to not operate in a strict ordered mode for clients that do no support the strict_order parameter (e.g., bridges). The only way for the MAC not to operate in a stricted ordered mode is for the forceStrict variable to be set to FALSE and the MAC client explicitly sets the strict_order parameter to FALSE. The strict_order mode should be a system configuration. For example, for rings with bridge clients (or clients that don't support the strict_order parameter), a means to turn off strict ordering is required. | Set the (null) behavior of the strict_order parameter to default to FALSE. Proposed text is: (null) - The default value is FALSE. | The standards should support a way for the RPR MAC to operate in both a strict ordered and non strict ordered mode for clients that don't support the strict_order parameter (e.g., bridge clients). | No effect. | R | J | ||||||||
| 0015 Closed | J | No specified manner to collect summary stats associated with rprSpan*Group and rprClient*Group MIBs. | 11-Mar-05 | 802.17-2004 | 580 | D.5 | Technical | Holness | Marc | No specified manner to collect summary (i.e, totals) stats associated with rprSpan*Group (e.g., rprSpanCurrentGroup, rprSpanIntervalGroup, rprSpanDayGroup, etc) and rprClient*Group (e.g., rprClientCurrentGroup, rprClientIntervalGroup, etc.) MIBs. Ceratin carrier customers may want a standard way to collecting the summary stats, as opposed to collecting the plethora of individual counters. | Within rpr[Span/Client][Current/Interval/Day/Stats]Group MIB, add the following objects: rpr[Span/Client]*[In/Out]ClassA[Frames/Octets], rpr[Span/Client]*[In/Out]ClassB[Frames/Octets], rpr[Span/Client]*[In/Out]ClassC[Frames/Octets]. | Service Providers may want to collect the rprSpan*Group and rprClient*Group stats on a more granular basis so that they don't get swamped by all of the fine granular stats. | No impact. | J | |||||||||
| 0016 | B | Range of rprIfKeepaliveTimeout object is (2..50) ms. | 11-Mar-05 | 802.17-2004 | 476 | D.6 | Technical | Holness | Marc | Range of rprIfKeepaliveTimeout object is (2..50) ms. However the state machine description provided in Section 11.6.2.2 states that the range should be (2..200) ms. This inconsistency needs to be resolved. | Change range of rprIfKeepaliveTimeout object to (2..200). | Consistency within the specifications. | No impact. | C | B | ||||||||
| 0017 | B | Range of rprSpanProtectionHoldOffTimer object is (0..500) ms. | 11-Mar-05 | 802.17-2004 | 476 | D.6 | Technical | Holness | Marc | Range of rprSpanProtectionHoldOffTimer object is (0..500) ms. However the state machine description provided in Section 11.2.3 states that the range should be (0..200) ms. This inconsistency needs to be resolved. | Change range of rprIfKeepaliveTimeout object to (0..200). | Consistency within the specifications. | No impact. | B | B | ||||||||
| 0018 Closed | W | 802.3 MAC attributes were mistakenly added to the PacketPHY. | 13-Mar-05 | 802.17-2004 | 416 | B.2.1.6.1 | Technical | Lemon | John | 802.3 MAC attributes were mistakenly added to the PacketPHY. | Remove the 802.3 preamble and IPG from the PacketPHY. | See attached text. | 1G and 10G PHYs are capable of working with without these 10/100 leftovers. | R | W | ||||||||
| 0019 | B | The classC credits are being saved before updating them. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | The classC credits are being saved before updating them. | Move "lastCreditC = creditC;" from first line to last line of the action for Row 9. | The credit amount is stored for comparison in subsequent runs through the shaper in Row 5. This is done to determine if frames are being held too long. So, the credit amount needs to be saved after shaper adjustment. | New equipment with this fixed will not impact equipment already deployed with this incorrect order of setting the saved value. | R | B | |||||||
| 0020 | B | The frame example shown in Figure E.8 shows the protocolType, and therefore the FCS, starting at the wrong offset into the frame. | 13-Mar-05 | 802.17-2004 | 594 | E.2.4 | E.8 | Technical | Lemon | John | The frame example shown in Figure E.8 shows the protocolType, and therefore the FCS, starting at the wrong offset into the frame. | Show protocolType (and therefore FCS) starting 16 bits into a 32-bit alignment of the frame. | Someone implementing what the figure shows would start the FCS 8 bits too early. | New equipment with this fixed will not interoperate with equipment already deployed with an incorrect offset for starting the FCS calculation. | R | B | |||||||
| 0021 | B | SM22 refers to the wrong state machine. | 13-Mar-05 | 802.17-2004 | 193 | 7.8.3.1 | Technical | Lemon | John | SM22 refers to the wrong state machine. | Change "TransmitCount" to "TransmitRoute". | It needs to be clear which statemachine is meant. | None. | R | B | ||||||||
| 0022 | B | SP3 and SP4 refer to the wrong frame type. | 13-Mar-05 | 802.17-2004 | 399 | 12.7.3.4 | Technical | Lemon | John | SP3 and SP4 refer to the wrong frame type. | In SP3, change "MA_CONTROL.request with an opcode value of OAM_ECHO_REQ" to "MA_CONTROL.request with an opcode value of OAM_FLUSH_REQ", and change "Echo flush formats" to "Flush request formats". In SP4, change "MA_CONTROL.indication with an opcode value of OAM_ECHO_IND" to "MA_CONTROL.indication with an opcode value of OAM_FLUSH_IND", and change "Echo flush formats" to "Flush request formats". | It needs to be clear which opcode and frame types are meant. | None. | R | B | ||||||||
| 0023 | B | Table 7.11, Table 7.12, and Table 7.13 direct taking the Min() of 0 and the credit value after being decremented for one byte. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | Table 7.11, Table 7.12, and Table 7.13 direct taking the Min() of 0 and the credit value after being decremented for one byte. | In Table 7.11 Row 1, Table 7.12 Row 1, Table 7.13 Row 1, and Table 7.13 Row 2, change "Min" to "Max". Move the definition of Max forward to Clause 7. | The current text would always drop the credits to zero or to negative credits for every byte transmitted. This check is supposed to be preventing the credits from dropping below zero. | None. | R | B | |||||||
| 0024 | B | Table 7.11 and Table 7.12 do not check at entry to the statemachine if the TICK time has expired. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | Table 7.11 and Table 7.12 do not check at entry to the statemachine if the TICK time has expired. | In Table 7.11, reverse the order of Row 1 and Row 2. In Table 7.12, reverse the order of Row 1 and Row 2. | The current text would always wait for no FE bytes to be available before providing new credits. | None. | R | B | |||||||
| 0025 | B | Table 7.11 and Table 7.12 make use of an undefined constant, NORM. | 13-Mar-05 | 802.17-2004 | 112 | 7.5.7.2.4 | 7.11 | Technical | Lemon | John | Table 7.11 and Table 7.12 make use of an undefined constant, NORM. | Define NORM, preferably in Clause 10 to be ageCoef * rateCoef. Maybe name it DENORM or denorm. | The current text does not specify what this value is intended to be. | None. | R | T | T | B | |||||
| 0026 | B | The description of Table D.2 incorrectly limits the applicability to the operational state of down. | 13-Mar-05 | 802.17-2004 | 468 | D.5.1.3 | Technical | Lemon | John | The description of Table D.2 incorrectly limits the applicability to the operational state of down. | Change "operational down state" to "operational state". | It is clear that this is supposed to be referring to the operational state, regardless of whether it is down or up. | None. | B | B | ||||||||
| 0027 Closed | J | The OAM service primitives and the MIB allow specification of a mac_protection parameter. | 13-Mar-05 | 802.17-2004 | 387 | 12.4 | Technical | Lemon | John | The OAM service primitives and the MIB allow specification of a mac_protection parameter. | Remove the mac_protection parameter from the OAM service primitives and the MIB. | The RingletSelection state machine does not allow control frames to be protected. Implying that the OAM frames can be protected leads to a false conclusion. | None. | R | J | ||||||||
| 0028 | B | The MIB specifies WTR and keepalive as being configured per ring. | 13-Mar-05 | 802.17-2004 | 474 | D.6 | Technical | Lemon | John | The MIB specifies WTR and keepalive as being configured per ring. | Move these configurations from the rprIfEntry to the rprSpanProtectionEntry | WTR and keepalive are specified in 11.2.3 to be per-span. | None. | R | B | ||||||||
| 0029 | B | The PerByte statemachine allows neither RATE_BASED nor SHAPER_BASED admission methods to be chosen. | 13-Mar-05 | 802.17-2004 | 250 | 10.4.1.4 | 10.5 | Technical | Lemon | John | The PerByte statemachine allows neither RATE_BASED nor SHAPER_BASED admission methods to be chosen. | Remove Row 16. Remove the condition from Row 15 (but leave as a comment as is done for Table 10.10 Row 8). | Row 16 conflicts with the PICS and with the rest of the text and could be interpreted to imply that one is allowed to not support any admission method. | None. | R | B | |||||||
| 0030 | B | transmitTpFrame is not being set to FALSE. | 13-Mar-05 | 802.17-2004 | 353 | 11.6.7.4 | 11.17 | Technical | Lemon | John | transmitTpFrame is not being set to FALSE. | Change "transmitTpFrame == FALSE;" to "transmitTpFrame = FALSE;". | C syntax interprets this to mean to check for equivalence and do nothing with the result whereas a set is desired. | None. | B | B | |||||||
| 0031 | B | The row descriptions for Row 3 and Row 4 are switched. | 13-Mar-05 | 802.17-2004 | 355 | 11.6.8.4 | Technical | Lemon | John | The row descriptions for Row 3 and Row 4 are switched. | Switch the row descriptions for Row 3 and Row 4. | The current statemachine is ambiguous as to which interpretation to prefer. | None. | R | B | ||||||||
| 0032 | B | holdoffTimeout and keepaliveTimeout are not shown to be using per-ringlet values. | 13-Mar-05 | 802.17-2004 | 326 | 11.6.2.3 | 11.12 | Technical | Lemon | John | holdoffTimeout and keepaliveTimeout are not shown to be using per-ringlet values. | Modify the statemachine table and 11.6.2.2 to correctly apply these on a per-ringlet basis. | Different spans canhave different characteristics and therefore can need different holdoff values and therefore also keepalive values. It is also clear from 11.2.3 that these are intended to by configured and measured on a per-ringlet basis. | None. | R | B | |||||||
| 0033 | B | There is no adminReqProtection defined. | 13-Mar-05 | 802.17-2004 | 327 | 11.6.3.2 | Technical | Lemon | John | There is no adminReqProtection defined. | Change all references to adminReqProtection to instead reference adminRequestProtection, or vice versa. | Correct and consistent variable names are needed, especially when so many similar names are provided. | None. | R | B | ||||||||
| 0034 | B | The statemachine rows 10, 11, and 12 do not correspond to the row descriptions. | 13-Mar-05 | 802.17-2004 | 342 | 11.6.5.6 | 11.15 | Technical | Lemon | John | The statemachine rows 10, 11, and 12 do not correspond to the row descriptions. | Change the row descriptions to match the statemachine. | The statemachine is correct and the row descriptions are not. | None. | R | T | B | ||||||
| 0035 | B | The row description for Row 12 is incorrect. | 13-Mar-05 | 802.17-2004 | 335 | 11.6.4.4 | Technical | Lemon | John | The row description for Row 12 is incorrect. | Change the row description to "Otherwise, no topology database update is needed." | Row 12 does not continue with database update. | None. | R | B | ||||||||
| 0036 Closed | J | The figure shows two links that don't exist. | 13-Mar-05 | 802.17-2004 | 323 | 11.6.1 | 11.28 | Technical | Lemon | John | The figure shows two links that don't exist. | Remove the link from ReceiveTpFrame to ParseTpFrame. Remove the link from ReceiveMonitor to ProtectionUpdate. | ReceiveTpFrame notifies TopologyControl of the received TP frame (via the Q_RX_TP_PARSE queue), and then TopologyControl calls ParseTpFrame. So the frame in enqued by ReceiveTpFrame and dequeued by ParseTpFrame, but only with the intermediate interaction of TopologyControl. A change in span status is detected by ReceiveMonitor, which then sets spanOperStatus. The change in spanOperStatus is detected by TopologyControl, which calls ProtectionUpdate. There is no direct linkage from ReceiveMonitor to ProtectionUpdate. | None. | R | J | |||||||
| 0037 Closed | J | This allows an FS to be replaced by an MS. | 13-Mar-05 | 802.17-2004 | 341 | 11.6.5.6 | 11.15 | Technical | Lemon | John | This allows an FS to be replaced by an MS. | Add the following row after Row 4: Condition: adminReqProtection[ri] == MS && myTopoInfo.spanProtState[ri] >= MS Action: spanProtAdmin = IDLE; adminReqProtection = NULL; Next State: MAIN | If you start with FS on the east side of a station and then command MS on the east side of the same station, the standard will currently allow the FS to be replaced by MS. | None. | R | T | J | ||||||
| 0038 | B | There is no PICS entry for the "may" in the definition of localWeight, and no corresponding text in the MIB definition. | 13-Mar-05 | 802.17-2004 | 242 | 10.2.2 | Technical | Lemon | John | There is no PICS entry for the "may" in the definition of localWeight, and no corresponding text in the MIB definition. | Add a PICS entry and correct the MIB description. | The PICS and MIB do not correspond to the standard. | None. | R | B | ||||||||
| 0039 | B | There is no MIB attribute for stabilityTimeout. | 13-Mar-05 | 802.17-2004 | 346 | 11.6.6.3 | Technical | Lemon | John | There is no MIB attribute for stabilityTimeout. | Add a MIB attribute for stabilityTimeout. | The configurable attribute is missing from the MIB. | None. | R | B | ||||||||
| 0040 | B | rprIfCurrentStatus is does not provide status and is missing most of 11.2.9. | 13-Mar-05 | 802.17-2004 | 480 | D.6 | Technical | Lemon | John | rprIfCurrentStatus is does not provide status and is missing most of 11.2.9. | Change rprIfCurrentStatus to rprIfCurrentDefects. Add the defects in 11.2.9 that are not included in this bit field. | Status implies much more than which defects are in effect. This list of defects is missing most of the defects. | None. | R | B | ||||||||
| 0041 | B | RprTopoImageEntry is missing an attribute corresponding to spanEdge[ri]. | 13-Mar-05 | 802.17-2004 | 489 | D.6 | Technical | Lemon | John | RprTopoImageEntry is missing an attribute corresponding to spanEdge[ri]. | Add an attribute corresponding to spanEdge[ri]. | This needs to be reported in the MIB. | None. | R | B | ||||||||
| 0042 | B | rprTopoImageWestProtectionStatus and rprTopoImageEastProtectionStatus are not statuses and are not bit fields. | 13-Mar-05 | 802.17-2004 | 492 | D.6 | Technical | Lemon | John | rprTopoImageWestProtectionStatus and rprTopoImageEastProtectionStatus are not statuses and are not bit fields. | Change rprTopoImageWestProtectionStatus and rprTopoImageEastProtectionStatus to rprTopoImageWestProtectionState and rprTopoImageEastProtectionState. Change them from bit fields to integers. | These provide the current protection state. Only one state can be active at a time. | None. | R | B | ||||||||
| 0043 | B | rprTopoImageStatus fields receivedBadFcs and receivedMultichokeFairness are not events indicating such things have been received. | 13-Mar-05 | 802.17-2004 | 493 | D.6 | Technical | Lemon | John | rprTopoImageStatus fields receivedBadFcs and receivedMultichokeFairness are not events indicating such things have been received. | Change receivedBadFcs to receivesBadFcs. Change receivedMultichokeFairness to receivesMultichokeFairness. Correct their descriptions to indicate that these advertise what a station wishes to receive, not some events that have happened. | The current names and descriptions are incorrect. | None. | R | B | ||||||||
| 0044 | B | Extraneous '{' and '}'s. | 13-Mar-05 | 802.17-2004 | 363 | 11.6.13.3 | Technical | Lemon | John | Extraneous '{' and '}'s. There is an extraneous '}' after the first for statement of SecondaryMacCount(), an extraneous '}' before the return statement of SecondaryMacCount(), and an extraneous '{' at the end of the line of the third for statement of SecondaryMacValidation(). | Remove extraneous '{' and '}'s. | Extra '{' and '}'s are syntactically incorrect. | None. | R | B | ||||||||
| 0045 | B | The protMisconfigDefect is not cleared even after the configuration mismatch has been corrected. | 14-Mar-05 | 802.17-2004 | 333 | 11.6.4.4 | 11.14 | Technical | Sultan | Bob | The protMisconfigDefect is not cleared even after the configuration mismatch has been corrected. This occurs because topoChanged is not set to TRUE in Table row 11.14.11 when a TpFrame is received with a new value tpFrame.prefs.wc. As a result, protMisconfigDefect = MismatchedProtection() is not invoked by table tow 11.16.9, and protMisconfigDefect is not cleared unless a topology change subsequently occurs. (request submitted on behalf of Wendy Lao who found this problem). | Insert the action topoChanged = TRUE in Table row 11.14.11. | Simple change that fixes problem. | None except to fix problem. | B | B | |||||||
| 0046 | B | DistantStateMax() does not return the correct value of awayState for cases in which a station has an edge, but the edge is not caused by the station on the far-end of the span. | 14-Mar-05 | 802.17-2004 | 339 | 11.6.5.5 | Technical | Sultan | Robert | DistantStateMax() does not return the correct value of awayState for cases in which a station has an edge, but the edge is not caused by the station on the far-end of the span. Specifically, the code on lines 38-44 describes an action only in the case that tp.spanEdge[ringlet] && tp.spanProtState[ringlet] == IDLE but does not describe an action for other cases of tp.spanEdge[ringlet]. (Reported on behalf of Sanjay Sharma of Fujitsu Network Communications). | // Edge reached. Determine whether or not idle edge. if (tp.spanEdge[ringlet]) { // Idle edge reached. Determine if reported by neighbor if (tp.spanProtState[ringlet] == IDLE) { idleEdge[ringlet] = TRUE; if (topoEntry[Other(ringlet)][1].valid && tp.macAddress != topoEntry[Other(ringlet)][1].macAddress) idleEdgeNotFromNbr[ringlet] = TRUE; } else { // Edge reached is not idle. Report away state. awayState = tp.spanProtState[ringlet]; } break; } | Simple fix returns expected awayState. | Corrects problem in existing equipment. | T | T | I | B | ||||||
| 0047 Closed | J | A station may become the head of a congestion domain based solely on the rate of transiting non-reserved traffic. | 14-Mar-05 | 802.17-2004 | 256 | 10.4.3.4 | 10.8 | Technical | Sultan | Robert | In the case of the aggressive fairness method, a station may become the head of a congestion domain based solely on the rate of transiting non-reserved traffic, even when the local station is not adding fairness-eligible traffic or when transiting fairness-eligible traffic is sufficient to exceed the rateLowThreshold without the contribution of the local station. In such cases, add rates within the congestion domain are unnecessarily (and repeatedly) throttled to a small value, significantly reducing ring utilization. | T | T | J | |||||||||
| 0048 | B | The definition of classCAccessDelayTimer suggests that the timer specifies the longest waiting time of any traffic waiting for transmission. | 14-Mar-05 | 802.17-2004 | 79 | 7.2.2 | Technical | Sultan | Robert | The definition of classCAccessDelayTimer suggests that the timer specifies the longest waiting time of any traffic waiting for transmission. The definition of classCAccessDelayTimerExpired suggests that the classCAccessDelayTimer specifies the time since the most recent transmission. In general, the latter definition makes it less likely that access-delay expiration will occur (same problem for classA and ClassB definitions. | Make both definitions of classCAccessDelayTimer and classCAccessDelayTimerExpired consistent with the definition of classCAccessDelayTimerThreshold. Specifically: classCAccessDelayTimer - Indicates the largest amount of time any classC add traffic having met requirements for transmission, has been waiting for transmission. classCAccessDelayTimerExpired - Indicates whether the access delay timer for classC add traffic has exceeded the classCAccessDelayTimerThreshold. (Similar changes for classA and C) | Simple fix, consistent with definition of classCAccessDelayTimerThreshold, preserves the effectiveness of the accessDelayTimer. | Allows accessDelay to be an effective means of congestion detection. | T | T | B | |||||||
| 0049 Closed | J | Table 7.10 Row 4 does not cover the case in which there are multiple frames waiting, and only some were sent. | 14-Mar-05 | 802.17-2004 | 108 | 7.5.6.4 | 7.10 | 7.10 | Technical | Sultan | Robert | Table 7.10—ClassBShaper state table row 4 increments the classBAccessDelayTimer when: ClassBEntryAvailable() && startingCreditB == lastCreditB. This increments the timer when there are frames waiting and no frames have been sent. The row does not cover the case in which there are multiple frames waiting, and only some were sent. | Add a row to the table for the case of ClassBEntryAvailable() && startingCreditB != lastCreditBclassBAccessDelayTimer. In this case, the accessDelayTimer takes its value from the frame remaining to be transmitted that has spent the longest time on the transmission queue. Since this method requires the maintainance of multiple time values, an alternative is to declare accessDelay based on the length of the queue of frames awaiting transmission. | Prevents accessDelayTimer mechanism from being defeated by a 'trickle' of transmitted traffic. | Allows accessDelay to be an effective means of congestion detection. | T | T | J | |||||
| 0050 | B | The value of creditS is always equal to zero. | 15-Mar-05 | 802.17-2004 | 115 | 7.5.7.4.4 | 7.13 | 7.13 | Technical | Caizzone | Giuseppe | According to Table 7.13 if creditS = Min(0, creditS - 1) as shown in row 1 or creditS = Min(0, creditS + 1) as shown in row 2, the value of creditS is always equal to zero. | In Table 7.13 row 1 replace Min(0,creditS-1) with Max(0,creditS-1) and in row 2 replace Min(0,creditS+1) with Max(0,creditS+1). In this way the minimum value of creditS is equal to zero | Minimum change | This is an obvious error and the implementors should have seen it. No particular effect is expected | R | B | ||||||
| 0051 | B | Echo frames are requested by the client, and not the management system. | 15-Mar-05 | 802.17-2004 | 381 | 12.1.4 | Technical | Bruckman | Leon | Echo frames are requested by the client, and not the management system. The text is wrong | "allows the management system" shall be replaced with: "allows the client" | Fix the text to reflect the standard | None | R | B | ||||||||
| 0052 | B | rprSpanStatsInOamEchoFrames and rprSpanStatsOutOamEchoFrames each mistakenly combined two counters from the standard. | 15-Mar-05 | 802.17-2004 | 525 | D.6 | Technical | Lemon | John | rprSpanStatsInOamEchoFrames and rprSpanStatsOutOamEchoFrames each mistakenly combined two counters from the standard. | Divide rprSpanStatsInOamEchoFrames into rprSpanStatsInOamEchoReqFrames and rprSpanStatsInOamEchoRspFrames. Divide rprSpanStatsOutOamEchoFrames into rprSpanStatsOutOamEchoReqFrames and rprSpanStatsOutOamEchoRspFrames. | The standard purposely counted the two types of echo frames separately, and the MIB was supposed to follow the standard. | None. | R | B | ||||||||
| 0053 Closed | J | The control frames counters in RprSpanCountersStatsEntry are in the wrong location. | 15-Mar-05 | 802.17-2004 | 525 | D.6 | Technical | Lemon | John | The control frames counters in RprSpanCountersStatsEntry are in the wrong location. | Move the control frames counters from RprSpanCountersStatsEntry (and associated span tables) to RprClientCountersStatsEntry (and associated client tables). | The standard counts control frames at client receive (Table 7.26) and client transmit (Table 7.33), and does not count control frames separately at span receive (Table 7.21) and span transmit (Table 7.36). | None. | R | J | ||||||||
| 0054 | B | DistantStateMax() does not correctly handle the 2-station case. | 15-Mar-05 | 802.17-2004 | 339 | 11.6.5.5 | Technical | Fan | Jason | The if statement if (ringlet != ri && topoEntry[Other(ringlet)][1].valid && tp.macAddress == topoEntry[Other(ringlet)][1].macAddress) { awayState = Max(awayState, tp.spanProtState[ri]); break; } is designed to prevent WTR from being pre-empted when a broken span is reconnected in a ring with 2 stations. WTR is being pre-empted because this if statement is not entered. The reason that the if statement is not entered is that the neighbor station is not yet valid, because TP frames that may be received over an SF link are discarded. | The remedy is to replace the if statement with: if (ringlet != ri && tp.macAddress == topoEntry[Other(ringlet)][1].macAddress) { awayState = Max(awayState, tp.spanProtState[ri]); break; } This enables the if statement to be entered in the two station case, so that WTR will remain if the neighbor station has not changed from before the span break. This does not cause a problem if the neighbor station has changed in the meantime (which requires that WTR be cleared). Once WTR is entered, the next TP frame received from the new neighbor will result in newNeighbor[rid] beoing set to true in Row 15 of Table 11.14, which will result in WTR being cleared in row 21 of Table 11.15. | See remedy. | Equipment with this change will enter WTR correctly on a 2 station ring. Equipment without this change will go directly from SF to IDLE in many cases on a 2 station ring. | R | T | B | |||||||
| 0055 Closed | J | Multicast or broadcast control frames can increment the ttlExpiredFrames counter. | 16-Mar-05 | 802.17-2004 | 139 | 7.6.3.8.4 | 7.22 | 7.22 | Technical | Lemon | John | Multicast or broadcast control frames can increment the ttlExpiredFrames counter. | Add "frame.ft == FT_DATA" to the condition for Table 7.22 Row 15. | TTL expiration was not supposed to be applied to control frames. | None. | R | T | J | |||||
| 0056 | B | The term "flow" is used without a definition. | 16-Mar-05 | 802.17-2004 | 121 | 7.6.2 | Technical | Lemon | John | The term "flow" is used without a definition here and on page 380. | Replace "flow" with "conversation". | IEEE 100 defines "flow" to mean something very different from how the term is being used in this standard. This standard provides no definition of "flow", thereby implying the IEEE 100 definition. The term "conversation" is defined in IEEE 100 and is consistent with the usage of "flow" in this standard. | None. | - | R | B | |||||||
| 0057 | B | The heading for the third row of Table 10.16 is incorrect. | 23-Mar-05 | 802.17-2004 | 281 | 10.5 | 10.16 | Technical | Lemon | John | The heading for the third row of Table 10.16 is incorrect. | Replace "LINK_RATE (bytes per ageCoef agingIntervals)" with "bytes per agingInterval" and add text explaining that the LINK_RATE is the value shown multiplied by the value of ageCoef. | It is not possible to show the actual LINK_RATE because the value of ageCoef is implementation dependent. | None. | - | R | B | ||||||
| 0058 | B | Incorrect row description for Row 10.5-5. | 23-Mar-05 | 802.17-2004 | 251 | 10.4.1.4 | 10.5 | Technical | Lemon | John | Incorrect row description for Row 10.5-5. | Change "A byte of fairness eligible transit traffic bound for a destination beyond the congestion point" to "A byte of fairness eligible transit traffic bound for a destination short of the congestion point". | This row handles traffic that is not going through the congestion point. | None. | - | R | B | ||||||
| 0059 | B | For a center-wrapping ring with bidirectional flooding, wouldn't that still be replicated with the we==1? | 05-Apr-05 | 802.17-2004 | 157 | 7.7.1.2.5 | Technical | James | David | I was looking over the ringlet selection, with simplifications (in my judgment) appropriate for RBR. A few questions arose. The text notes that: >>For wrapping rings, if the frame is not replicated, the we field is set. >>For wrapping rings, if the frame is replicated, the we field is not set. >>For steering rings, the we field has no meaning and is not set. What about a center-wrapping ring with bidirectional flooding. Wouldn't that still be replicated with the we==1? I would have thought that was necessary to be protected. | Correct text as appropriate. | - | R | B | |||||||||
| 0060 Closed | J | Incorrect ringlet selection for a bidirectional flooded frame on a center-wrapped station. | 05-Apr-05 | 802.17-2004 | 164 | 7.7.1.6.4 | 7.29 | Technical | James | David | This code appears to send a bidirectional flooded frame on both ringlets. This will not work on a center-wrapped station. Instead, they should be sent through the same datapath, but with distinct frame.ri identifiers. | 1) Provide text that clarifies how bidirectional frames are processed on a center-wrapped station, so the intent is clear. 2) Revise state machines to track the text of (1). | - | R | T | J | |||||||
| 0061 Closed | J | Problems with topo frames and fairness frames for a center-wrapped station. | 05-Apr-05 | 802.17-2004 | 164 | 7.7.1.6.4 | Technical | James | David | I believe the Transmit states will send all topo frames to the single connected datapath on a center wrapped ring. This should not be forced to be the case. Also, its unclear how fairness frames go across the wrapped center-wrapped station. | 1) Provide text that clarifies how control frames are processed, so the intent is clear. 2) Revise state machines to track the text of (1). | - | R | T | J | ||||||||
| 0062 | B | Extra space in "size Stq". | 05-Apr-05 | 802.17-2004 | 477 | D.6 | Technical | James | David | Extra space in: size Stq | Change: size Stq ==> sizeStq | - | R | B | |||||||||
| 0063 | B | The rprOamRequestCount is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 502 | D.6 | Technical | James | David | The rprOamRequestCount no has meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamRequestCount material at the end of page 502 to top of page 503 as well as other rprOamRequestCount related material. | - | R | B | |||||||||
| 0064 | B | The rprOamTimeout is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamTimeout has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamTimeout material at the top of page 503 to further down on page 503 as well as other rprOamTimeout related material. | - | R | B | |||||||||
| 0065 | B | The rprOamControl is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamControl has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamControl material at the top of page 503 to further down on page 503 as well as other rprOamControl related material. | - | R | B | |||||||||
| 0066 | B | The rprOamResponseCount is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamResponseCount has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamResponseCount material at the middle of page 503 to further down on page 503 as well as other rprOamResponseCount related material. | - | R | B | |||||||||
| 0067 | B | The rprOamAvResponseTime is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamAvResponseTime has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamAvResponseTime material at the middle of page 503 to further down on page 503 as well as other rprOamAvResponseTime related material. | - | R | B | |||||||||
| 0068 | B | The rprOamResponseStatus is not cross-referenced to an RPR variable. | 05-Apr-05 | 802.17-2004 | 503 | D.6 | Technical | James | David | The rprOamResponseStatus has no meaning within the current definition, but appears to be from the history of when we assumed the MAC would support some sort of auto-retry and timeouts. Furthermore, there is no cross-reference to an RPR variable, which reinforced the aforementioned thoughts. | Delete rprOamResponseStatus material at the bottom of page 503 to top on page 504 as well as other rprOamResponseStatus related material. | - | R | B | |||||||||
| 0069 | B | Wrong name: "toClientUcastClassBCirAFrames". | 05-Apr-05 | 802.17-2004 | 556 | D.6 | Technical | James | David | Wrong name: toClientUcastClassBCirAFrames | Change: toClientUcastClassBCirAFrames to toClientUcastClassBCirFrames | - | R | B | |||||||||
| 0070 Closed | J | There is an entry for client-in broadcast counts, but not multicast. | 05-Apr-05 | 802.17-2004 | 558 | D.6 | Technical | James | David | There is an entry for broadcast counts, but not multicast. | Insert something like the following: rprClientStatsInMcastFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of MAC to client multicast frames. This is used only when deriving the multicast and broadcast packet counters for the interface MIB." REFERENCE "IEEE 802.17 Subclause 7.2.5, toClientMcastFrames" ::= { rprClientCountersStatsEntry 18 } | - | R | J | |||||||||
| 0071 Closed | J | There is an entry for client-out broadcast counts, but not multicast. | 05-Apr-05 | 802.17-2004 | 561 | D.6 | Technical | James | David | There is an entry for broadcast counts, but not multicast. | Insert something like the following: rprClientStatsOutMcastFrames OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of client to MAC multicast frames. This is used only when deriving the multicast and broadcast packet counters for the interface MIB." REFERENCE "IEEE 802.17 Subclause 7.2.5, fromClientMastFrames" ::= { rprClientCountersStatsEntry 35 } | - | R | J | |||||||||
| 0072 | B | rampUpCoef does not belong in the condition of Row 5. | 20-May-05 | 802.17-2004 | 258 | 10.4.4.4 | 10.9 | Technical | Wu | Guoliang | Condition of Row 5 contains error. The condition is: localFairRate/localWeight >= unreservedRate[myRi] - rampUpCoef. On the Right Hand Side of the inequality, unreservedRate is in bytes and rampUpCoef is a pure number. | Revise the condition of Row 5. Row 5 description on Page 259 mgiht be updated for alignment with Row 5 contents. Necdet Uzun proposed the following remedy (in 5/17/2005 email): localFairRate/localWeight >= unreservedRate[myRi]. | - | R | T | B | |||||||
| 0073 | B | allowedRate is calculated twice in Row 5 and Row 16. The later calculation overrides the early one. | 20-May-05 | 802.17-2004 | 258 | 10.4.4.4 | 10.9 | Technical | Wu | Guoliang | allowedRate calculated twice in Row 5 and Row 16. The later calculation overrides the early one. One of the calculations should be removed or changed. | Two options: A) delete allowedRate calculation in Row 5, B) add normLocalFairRate calculation in Row 5 and change next state to RETURN. | Eliminates double calculation of allowedRate. | Option A does not affect equipment behavior. Option B ramps up allowedRate towards maxAllowedRate, which is a reasonable behavior. | - | R | B | ||||||
| 0074 | B | Incorrect comparison between fairRate and receivedRate. | 31-May-05 | 802.17-2004 | 262 | 10.4.5.4 | 10.10 | Technical | Bruckman | Leon | In Table 10.10 the condition of row 5 is: localCongested && normLocalFairRate | Reaplace the condition in Table 10.10 row 5 to: localCongested && normLocalFairRate <= receivedRate. For consistency, the condition in row 7 can be changed to: downstreamCongeted && normLocalFairRate > receivedRate. | Minimal change that fixes a problem | None | - | R | B | ||||||
| 0075 | B | Wrong table name. | 01-Jun-05 | 802.17-2004 | 189 | 7.7.10.4 | Technical | Bruckman | Leon | Wrong table name in the first sentence of the section. | Change: The TransmiCount to: The TransmitRoute | Consistency | None | - | R | B | |||||||
| 0076 | B | A frame with a multicast DA can be sent on the ring with frame.fi = FI_NONE. | 13-Jul-05 | 802.17-2004 | 163 | 7.7.1.6.4 | 7.29 | Technical | Jones | Peter | In row 21 in this state machine, the text permits a frame with a multicast DA and a provided flooding form of FLOOD_NONE to be sent on the ring with frame.fi = FI_NONE. Transmitting a multicast frame with FI_NONE is not valid | Insert a new row between 20 and 21 with Condition = !unicast(frame.da), Action = “-”, State = “FORM”. Change rows 24 to 27 to remove the test for “Unicast(frame.da)” | This will ensure that all multicats frames are sent with the frame.fi set to FI_BIDIR or FI_UNIDIR, and also removes the need to test for "unicast(da)" in later rows within the state. | none | - | R | B | ||||||
| 0077 Closed | J | If there's a fiber loopback, ReceiveTpFrame can not report this specific error, just a large scope error of miscabling. | 25-Jul-05 | 802.17-2004 | 355 | 11.6.8.4 | 11.18 | Technical | li | jian | If there's a fiber loopback, ReceiveTpFrame state can not clear notify this error, just detect a large scope error - miscable. | 1. insert a row between row4 and row5, the content in new row is following: condition " frame.ri!=ri && frame.ttl==MAX_STATION && frame.sa==myMacAddress" action "loopbackDefect[ri] = TRUE" state "START" 2. add content as following at the action of row5: loopbackDefect[ri] = FALSE | Clearly and definitely islate the fiber loopback that is a very normal problem. If we add this remedy, we can easyly notify this problem, rather than a widely common problem - "miscabling". | very simply. | - | - | J | ||||||
| 0078 | B | ResetStqWatermarks() resets stqHighWatermark to stqSize. | 28-Jul-05 | 802.17-2004 | 254 | 10.4.2.3 | Technical | Sood | Mohit | Logical error in ResetStqWatermarks() routine in Section 10.4.2.3. This routine resets stqHighWatermark to stqSize. As a result, in the routine RecordStqWatermarks(), stqHighWatermark never gets updated to the highest measured occupancy of STQ. It will always remain at stqSize (maximum size of STQ). | stqHighWatermark should either be reset to 'zero' in ResetStqWatermarks() routine in Section 10.4.2.3. | RecordStqWatermarks() updates stqHighWatermark by calculating the maximum between previous value of stqHighWatermark and stqDepth (current occupancy of STQ). If stqHighWatermark is reset to stqDepth or 'zero', then stqHighWatermark will not be fixed at stqSize, but will represent the highest measured occupancy of STQ. | Currently use of stqHighWatermark is not specified in the standard. However, whoever uses this value (say client), would see a correctly measured value of stqHighWatermark. | - | - | B | |||||||
| 0079 | B | Wrong routine name, InitLowPassFilteredRates(), in Table 10.6. | 29-Jul-05 | 802.17-2004 | 255 | 10.4.2.4 | 10.6 | Technical | Sood | Mohit | Wrong routine name : InitLowPassFilteredRates(), in table 10.6 | Change InitLowPassFilteredRates() to InitLpFilteredRates() | Refer to routine definition, 10.6 in Section 10.4.2.3 on page 253 | None | - | - | B | ||||||
| 0080 | B | frtt is computed before LrttToTail is computed. | 23-Sep-05 | 802.17-2004 | 277 | 10.4.10.5 | 10.15 | Technical | Sood | Mohit | Table 10.15, lines 11 and 12 : FRTT is computed before LRTT-To-Tail is computed. This is a redundant computation, since the same computation is done again in line 18. | Remove "frtt = fdd + lrttToTail;" from lines 11 and 12 and let it remain in line 18. | Based on the formula "frtt = fdd + lrttToTail", 'frtt' should be computed only after both 'fdd' and 'lrttToTail' have been computed, which is OK for line 18. But there is no point in calculating 'frtt' in lines 11 and 12. | None | - | - | B | ||||||
| 0081 | B | The MAC service interface provides the number of hops to the congestion point, not the nearest congested station. | 25-Sep-05 | 802.17-2004 | 56 | 6.3.1 | Technical | Sultan | Robert | The statement "the MAC service interface also provides the number of hops to the nearest congested station." is not strictly correct. The MAC service interface provides the number of hops to "the congestion point" or "the head of the congestion domain in which the local station lies". | Change "For service class classC, the MAC service interface also provides the number of hops to the nearest congested station." to "For service class classC, the MAC service interface of a station lying within a congestion domain also provides the number of hops to the head of the congestion domain in which that station lies." | More accurate description. | None. | - | - | B | |||||||
| 0082 Closed | J | Add a timestamp mechanism for oam echo request/response frame. | 27-Sep-05 | 802.17-2004 | 409 | 12.3.1 | 12.4 | Technical | li | jian | Add a timestamp mechanism for oam echo request/response frame just as LRRT frame to remove the latency of host dealing with. | just like the LRRT frame, add request-send timestamp(4 bytes), request-receive timestamp(4 bytes) and response-send timestamp(4 bytes) in oam echo request and response frame. When receive the response, mark the current time. So the delay time of oam is current-time - request-send - (response-send - request-receive). | 1. get the ClassA/ClassB/ClassC service delay time on RPR ring. 2. remove the host latency. 3. increase the precision of delay time. | 1. revise the oam echo request/reponse frame playload. 2. give the correct timestamp when send or receive oam echo frame. 3. using the timestamp to caculate the delay time. | - | - | J | ||||||
| 0083 Closed | J | Problems of cross-ring RPR reliability and rapid switchover. | 29-Sep-05 | 802.17-2004 | 624 | F | Technical | li | jian | The problems of cross RPR bridge ring reliability and rapid switchover. When two RPR bridge rings intersect, usually two or more stations are deployed for exchanging packets between the rings to ensure the reliability.Since they are in the same broadcast domain, a broadcast storm will be generated if no restriction is made on the intersecting stations. In such a case, we can resort to the Layer 2 Spanning Tree Protocols, such as STP and RSTP for solution. Since the protocols are limited by the algorithm, the convergence speed is slow. | To solve this problem, we can use a mechanism where one from the intersecting stations is selected as the main node to exchange traffic between two rings while the other stations are backup and do not exchange traffic. If a fault comes out at the main station, the function of traffic exchange will soon be switched to the backup stations within 50ms through the new protocol and RPR topology monitoring, ensuring the reliability and rapid switchover between rings.The detail is just as following: 1. Group the intersecting stations, and set the respective station ID, group ID and station priority. 2. Add a kind of control packet on the RPR. Advertise the information on each station in the group through the two RPRs in a multicast or broadcast manner. The station with highest priority acts as the main station, responsible for forwarding packets that cross rings, while others are backup stations. 3. backup stations need to store the MAC address of the current main station in the two rings. If the RPR topology changes, the backup station needs to check for its interconnection with the main station in both rings. If yes, no processing will be done. If not, a control packet will be sent out for selecting a station with the highest priority as the main station from the backup stations that are interconnected with the two rings. 4. Add a new control packet and send it out periodically. The main station sends out a control packet whenever the topology changes. It should quit from the main station mode when one main station receives control packets from the station with higher priority in the two RPRs. 5. Through the packet exchange and the application of topology, the rapid switchover between the main station and the backup station can be implemented. | 1. Solve the problems of cross RPR bridge ring reliability and rapid switchover. 2. Mitigate slow convergence of STP and RSTP. | Add a new protocol on RPR to complete the information advertising as well as negotiation on the switchover between the main and backup stations. | - | - | J | |||||||
| 0084 | B | frame.ri of an FDD frame is wrongly assigned the value of receivedRi. | 30-Sep-05 | 802.17-2004 | 272 | 10.4.9.4 | 10.14 | Technical | Sood | Mohit | Table 10.14, lines 1 and 3: 'frame.ri' of an FDD frame is wrongly assigned the value of 'receivedRi', which is the received ringlet ID of a FAIR frame. A FDD frame, in this case would take the (feedback) path traced by FAIR frame and not the actual data path. So, instead the FDD frames would be received by fairness instance related to the opposite ringlet instead of being received by the head (fairness instance) of congestion domain. As a result, the FRTT value would not be calculated at the head and shall remain 'zero'. This would drastically affect the working of Conservative method of rate adjustment. | Change "frame.ri = receivedRi;" in lines 1 and 3 to "frame.ri = myRi;" | The path of a FDD frame is same as the path taken by a data frame. Remember the purpose of sending FDD frames is to find the differential delay between Class A and Class C data frames. | The effect is relevant if the head of congestion is using Conser |