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