| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I’m probably not doing a good job of explaining myself. I was looking at this attribute as a capability. Most capabilities seem to be permanently present within the ONU, however some capabilities may be semi-permanent,
such as an SFP* module in an ONU pluggable port, specifically on the UNI side since this would not cause an ONU reset, causing rediscovery of capabilities. I guess the question is, how important is it for this information to be available to the OLT and would
it be okay for us to just expect the OLT to query the information if it deems it necessary for a decision making process? I also don’t think we could expect that a LOS event would always directly precede a pluggable module removal. Technically a LOS event
could precede it by days or longer before a module is removed, but this is probably an implementation detail.
If the answer/consensus is that this is a vendor specific implementation item I could see that making sense.
Ryan From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
On Behalf Of Glen Kramer If we use aMauType, it should go into the MAU management section. This is a basic attribute and the sections in 1904.4 correspond to sections in 802.3 Clause 30 where these attributes are defined. If TRX module is replaced on a live ONU, on PON side, this causes ONU re-registration. On UNI side, there are Loss of signal alarms already defined. This alarm can be a trigger for the NMS to re-query the UNI
port type when the signal returns. Glen From: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>
Marek Just taking a brief look through the draft, why not Section 14.3.3 – MAU Management? There’s already one attribute in that section, aMediaAvailable (0x07/0x00-47), that seems somewhat aligned in function. On a slightly different note, this is something that’s presumably discovered during initialization, however any thoughts on what should happen if this media interface is removed or added after initialization?
Should the insertion or removal of this ”media” somehow trigger a notification of some sort to the OLT? Ryan From:
stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
On Behalf Of Marek Hajduczenia CAUTION: The e-mail below is from an external source.
Please exercise caution before opening attachments, clicking links, or following guidance.
Dear colleagues, I started looking at the Action Item #44 from the yesterday’s call
In IEEE Std 802.3ca, we extended the aMAUType attribute in 30.5.1.1.2, adding a lengthy list of MAU types, which correspond to the optical module type. A few examples follow (I truncated the list, it is very long): (…snip…) 25/10GBASE-PQG-D3 One single mode fiber, 1 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, high power class, as specified in Clause 141 25/10GBASE-PQG-U2 One single mode fiber, 1 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, medium power class, as specified in Clause 141 25/10GBASE-PQG-U3 One single mode fiber, 1 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, high power class, as specified in Clause 141 25/10GBASE-PQX-D2 One single mode fiber, 1 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, medium power class, as specified in Clause 141 25/10GBASE-PQX-D3 One single mode fiber, 1 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, high power class, as specified in Clause 141 (…snip…) 50/10GBASE-PQG-U3 One single mode fiber, 2 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, high power class, as specified in Clause 141 50/10GBASE-PQX-D2 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, medium power class, as specified in Clause 141 50/10GBASE-PQX-D3 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 10.3125 GBd burst mode reception, high power class, as specified in Clause 141 50/10GBASE-PQX-U2 One single mode fiber, 2 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, medium power class, as specified in Clause 141 50/10GBASE-PQX-U3 One single mode fiber, 2 × 25.78125 GBd continuous reception / 1 × 10.3125 GBd burst mode transmission, high power class, as specified in Clause 141 50/25GBASE-PQG-D2 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 25.78125 GBd burst mode reception, medium power class, as specified in Clause 141 50/25GBASE-PQG-D3 One single mode fiber, 2 × 25.78125 GBd continuous transmission / 1 × 25.78125 GBd burst mode reception, high power class, as specified in Clause 141 (…snip…) … and that got me thinking about where to add the new management attribute that would map into aMAUType Clause 30 attribute. Subclause 14.3.2 already focuses on “PHY management”, and it has three attributes mapping into Clause 30 attributes
already, i.e., aPhyType, aSymbolErrorDuringCarrier, and aPhyAdminState. I feel it would be most natural to add aMauType attribute into the “Object group: PHY management” and we just need to decide what the leaf would be. Seems like 0x00-26 is the next one
available. Are there any concerns with this approach? Regards Marek To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 The contents of this e-mail message and
To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 |