RE: [EFM] OAM transport...
Matt, just replying to #10 for now:
10) PON. The P2P OAM is relatively straightforward. Are there any PON
implementation specifics that need to be addressed? How does the OAM
data rate change on a p2mp link, for example. Are there new/other
security threats? Is there, and should there be, any relationship to
the PON control protocol(s) (currently MPCP)?
-------------------------------------
[dave] Arguably, ranging and registration in PON are OAM functions. The
issue with PON and OAM is that OAM is not usable bi-directionally until the
ONU has ranged and has been provisioned (at a minimum, this means its
transmitter has been enabled by some message sent by the network operator).
On top of that, the ONU can only receive OAM messages, but not reply, unless
it is granted bandwidth to do so. So it seems OAM for PON may need to work
in conjunction with the data slot scheduling of the OLT. Maybe OLT
automatically includes a grant when it sends an OAM message that needs a
reply (but there is still the issue that it needs to be ranged, but not
necessarily registered).
Maybe we should add the "P" back to OAM to get OAM&P. Only a minimal set of
P-commands would be required/mandatory. Like transmitter enable/disable.
It's not a full-blown provisioning, but transmit disable/enable seems to me
to fall squarely under the P category, and applicable to P2P also.
Another possible uniqueness of PON is to store latest operational state
(doesn't apply to P2P), such as ranged, or range attempted but not
successful, or registered, or registration attempted but not successful,
lost lock, number of retries, etc. This state could be read locally, or
remotely (in the cases where the link is established anyway). These are
low-level things, so I don't think they can be victims of the "out-of-scope"
paintbrush.