Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Glen, Thank you for your response. --kan-- -- Kevin A. Noll Sr. Director, Systems Architecture Tibit Communications kevin.noll@xxxxxxxxxxxx From: Glen Kramer <glen.kramer@xxxxxxxxxxxx> Kevin, Please see below. -Glen From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Glen, In our previous email exchanges we discussed how UMT could support a use case in which a remote “OAM Manager” is managing multiple ONUs on an EPON. Reference the attached diagram. In my understanding of OAM, there is a one-to-one relationship between OAM instances. In other words, there must be an OAM instance in the “Manager” for every ONU that is being managed. Further, there is a
one-to-one relationship between the MAC and the OAM entity. [GK: ] Correct If these two statements are correct, then does it correctly follow that the “Manager” would need multiple instances of MAC+OAM+UMT? [GK: ] Correct If multiple MAC+OAM+UMT instances are required on the “Manager”, then does that mean that the “Manager” needs to have a NIC card for each ONU that is to be managed or could a “virtual” MAC be established for
each? If a “virtual MAC” is the solution, then is there a standard to which we can point to support this? [GK: ] Yes, 802.3ah, 802.3av, and 802.3ca all do this. But they provide physical-layer isolation using LLID, so MACs don’t even see the traffic that belongs to other virtual MACs. For what
we need to do, this is an overkill. The 1904.2 standard does not need to explain how to use virtual MACs and it does not need to point to other standards, because implementing these virtual MACs does not impact interoperability
between the manager and the managed stations or between the manager and the switch next to it. The model that the standard assumes is just a generic 802 architecture where each OAM client is a separate device (see below). A vendor may implement an optimized product where separate
devices shown inside the red box are all merged into a single device. From the outside of that red box, it should impossible to distinguish the optimized implementation from the model. If the model works, then the optimized implementation with virtual MACs
also works. Anyone with design experience in 802 architecture will understand what a device should do to behave according to the model, but as standards committees often say – optimization is optional. If a vendor doesn’t know how to implement such an optimization,
they should just stick with the model. To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1 |