Re: [EFM] OAM transport...
We've been trying to keep the registration/ranging type functions out of
OAM group although the certainly fall within the "OAM" term. One of our
requirements is that anything that is required for link operation (PON
grant request, auto-negotiation, etc) shouldn't fall to the OAM group.
It is an OAM function, but it seems better to distribute the function to
the technology specific group.
There are certainly PON specific variables that will need to be covered,
but I don't see that as a major hurdle for any transport mechanism.
- Matt
"Horne, David M" wrote:
>
> 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.