| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
When the UNI is pluggable, for example, 1GE, it would report 1000BASE-X, irrespective of what you plug into it. I do not think it will need to change state / value Marek From: Tucker, Ryan R <Ryan.Tucker@xxxxxxxxxxx> I don’t feel strongly about it, just noticed that section and the naming seemed consistent/appropriate. You’re right about it from a PON perspective, but I was thinking about this from a general perspective but more specifically, could a UNI port be a pluggable? That function might be useful in that case. Thoughts? 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. I do not have a personal preference, as long as we map from the 802.3ca Clause 30 attribute. It is all arbitrary anyway. I am not sure how a media interface be added / removed? If that is PON interface, that would mean replacing optics and changing it with another one without rebooting the ONU? Marek 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 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 |