Generally, the OLT pulls the ‘capability’ information if and when it needs it. A particular ONU can register and operate without OLT querying any capabilities at all.
In this particular example, we need to discuss few issues separately.
1) Should aMauType be treated as ‘HW capability’ type of attribute or as ‘Dynamic Configuration query’ type? It is a base attribute defined in 802.3, and .3 does not make a clear distinction (In 802.3 ‘capabilities’ means a different thing – it is a group of packages, where each package represents a collection of related attributes and features)
We can decide to treat this attribute as a capability or as a configuration. If we treat it as capability, then for the pluggable optics case, this attribute would report “unknown”. And then the specific module plugged in would be queried separately. To query a plugged module, I suppose the ONU OAM would need to read a certain field in the module’s ROM. It is almost like the “UNI Label description” TLV we discussed yesterday, but this time, the text would describe the installed module.
If we decide to treat this module as configuration, we would just report the current state, i.e., the specific module that happens to be plugged in. We would use any one of the pre-defined enumerated values from 802.3, 30.5.1.1.2. This seems easier, but it does not convey to the NMS the information that a specific module is pluggable or fixed. Even so, I think this approach would be more consistent with how aMauType is used in general.
2) How OLT would know about changed configuration or conditions?
According to OAM protocol, the ONU is not allowed to generate a response (i.e., a variable container TLV) without receiving a request first. So, the ONU cannot just volunteer any query responses on its own. But ONU can generate alarms and piggy-back them in any OAMPDUs, including the keep-alive OAMPDUs. Usually, the approach is that any change/event worth knowing about has an associated alarm. There is a number of such event codes:
An alarm is generated when event occurs and again when even clears. So, in our specific example about pluggable optics, LoS state can persist for a long time (days), but NMS would query the optics type when it receives the alarm that the LoS event has cleared, i.e., when the signal is detected again. Or it can query it anytime when a technician tries to debug a customer complaint remotely.
Glen
From: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>
Sent: Wednesday, July 14, 2021 11:46 AM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
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
Sent: Wednesday, July 14, 2021 11:53 AM
To: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx>; STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: RE: [1904.4 TF] [EXTERNAL] Action item #44
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>
Sent: Wednesday, July 14, 2021 9:47 AM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] [EXTERNAL] Action item #44
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
Sent: Wednesday, July 14, 2021 9:51 AM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Action item #44
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
44 | Attribute to discover optical module version |
|
|
| Assigned | Marek Hajduczenia |
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
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
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
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