[EFM] Re: OAM transport... OAM in Frames
On Saturday, February 2, 2002, at 05:05 PM, Matt Squire wrote:
> I'm sending this note out on the main EFM list rather than the EFM OAM
> list in hopes of getting feedback from a wider audience. In the OAM
> group, we have to decide on a method for transporting OAM data between
> the stations on a link. There are several proposals that have been put
> forth for OAM transport. At the last meeting, two proposals were active
>
> Proposal 1. Transport OAM bits in regular Ethernet frames at the MAC
> control layer. This proposal is described in
> http://www.ieee802.org/3/efm/public/jan02/gentry_1_0102.pdf.
This is the proposal I'm describing here.
> 1) Standardization complexity - How much do we have to change/write in
> the 802.3 specification to support this transport mechanism? Being that
> I'm personally very lazy, less is better. Which clauses would be
> effected and to what extent in each clause?
For OAM in Frames, we would need to change the following:
Clause 30/45 - (Management) to add a new oRemoteEntity object class
Clause 31 (MAC Control) - to add an OAM section and describe frame formats
Annex 30A - to add OIDs for new managed objects
Annex 43B - to add OAM types to the Slow Protocols list
> 2) Implementation complexity. Again, back to me being lazy, how much
> work is it to implement the transport mechanism? What functional blocks
> in the 802.3 spec need to be changed? How much new silicon/software is
> needed for an implementation (relative to the alternate proposal(s))?
> What is the component level backward compatibility (ie how much existing
> hardware can I use)?
For many existing designs, OAM in Frames can be implemented entirely
in firmware. Though the 802.3 spec has no facilities for prioritization
of packets, much existing gear has extensive support for different
priorities and QoS levels. If the hardware has a "highest" priority queue
which can be accessed by management software, it likely can be used
to implement OAM in Frames. So long as the implementation matches
the externally visible behavior specified in dot3, it will be compliant.
Likewise in the CPE gear, there is often a very small CPU of some
description to handle various housekeeping functions such as
autonegotiation
for the client-side 10/100 BASE-T. The intention is that a CPU with
very small resources will be able to implement the OAM function for the
CPE.
> 3) Bandwidth transparency. What is the effect on user data with respect
> to the OAM transport (ie delay/bandwidth implications of adding OAM to a
> link)? Why is this acceptable?
OAM in Frames is In Band. The OAM information is carried in packets.
As such, they consume bandwidth on the link. The bandwidth consumption
is minimal: there is an upper bound on the number of OAM packets per second
which can be sent, and that upper bound will be quite small. At the moment
5 packets per second is suggested, and even if we decide we need a higher
limit it will still be only a tiny fraction of the link.
I don't believe this is a real issue. The entire capacity of an ethernet
link is not now and has never been available to carry user traffic. A
1 gigabit ethernet link will not carry exactly 1,000,000,000.0 bits per
second of user data. The capacity of the link has to be de-rated by the
fraction of time spent sending IPGs, by the amount of bandwidth consumed
by MAC Control PAUSE frames, etc. Ethernet is not a clear channel, and
it cannot be marketed as though it were.
I expect many deployments will also use SNMP or other protocols to
manage the sophisticated (and proprietary) capabilities of their ONUs,
like VoIP, video distribution, encryption keys, or other capabilities.
The bandwidth consumed managing the infrastructure must also be accounted
for before guaranteeing a bandwidth to the subscriber. OAM is just another
factor in the calculation.
> 4) Applicablity to non-EFM PHYs/MACs. EFM will be defining new PHYs
> over which we know OAM will operate. Can the OAM transport mechanism be
> applied to other (non-EFM) PHYs? For example, people are using some 1G
> fiber solutions for access now. Can the OAM transport mechanism be
> applied to the current 'first mile' solutions? Should it apply to
> current 'first mile' solutions or to other applications of Etherent?
Gigabit ethernet and a single mode variant of 100 Megabit have both
attracted significant interest for access networks. I'm even aware of
a carrier which uses 10/100 BASE-T from RTs in the field out to the
subscriber premises, though I doubt this practice will be widespread.
Defining OAM to use frames means it can be used with any PHY. You
could run OAM in Frames over everything from 1BASE5 to 10 Gig. It allows
use of existing PHYs, and it imposes no new requirements on future
PHYs. Ethernet is a packet network, defining OAM to use packets makes is
usable on any PHY defined for Ethernet.
> 5) Security. We've had some detailed discussions at the meetings on
> security and threats in the access market. How are threats such as
> denial of service or theft of service addressed by the OAM transport?
> Should these issues be addressed?
I don't believe theft of service is an issue for OAM. The functionality
being discussed in the OAM track is for monitoring and reporting, and
not involved in whether to allow a subscriber to access the network.
Carriers would rely on measures such as provisioning of the line (for
P2P) or an authenticated login to control subscriber access.
Denial of Service is an issue in any packet switched network, if a
particular end node can generate more traffic than the destination can
handle.
For OAM in Frames the main issue wrt Denial of Service is in the
implementation: do not allow a DoS attack from one subscriber (or port)
to hold up processing of OAM for other subscribers (or ports). This is
an issue above the MAC, and is a question of fairness and resource limiting
between MACs.
Finally, there are a few environments which are extremely concerned about
security, even to the point of preventing information leakage. I do not
believe 802.3ah should define new authentication mechanisms, but that we
should provide the hooks to allow existing authentication mechanisms to
affect OAM operation. Details are in the presentation Matt linked to above.
> 6) Responsiveness. What is the comparative responsiveness of the
> transport mechanism? What kind of responsiveness is necessary for the
> problem?
Actually, I don't think the response requirements for OAM are extremely
tight. The tightest requirement is probably for a "dying gasp" after
a catastrophic failure of some sort. Even then, a reasonable ONU design
can continue to operate for milliseconds without resorting to expensive
measures with batteries and charging systems.
Nonetheless, the MAC Control layer can insert a frame at any time,
so an OAM frame would have to wait for at most one maximum sized frame.
We need to avoid defining OAM functions with extraordinarily tight
requirements for response time. The response time is greatly affected by
the slot time in an ePON, and on the Copper PHYs if interleaving is
adopted it will also have an affect on the responsiveness. We don't want
to add unreasonable requirements on the ePON or Copper tracks.
> 7) Data rate. Is the data rate for OAM transport fixed, variable,
> configurable, or what? What data rate is necessary to support OAM
> function?
There must be an upper bound on the bandwidth and resources consumed
by OAM. That way performance guarantees can be made and SLAs written
to account for the bandwidth used for OAM.
> 8) Market acceptance. What do you view the market requirements for an
> OAM transport mechanism are, and why does this transport suffice?
OAM is only useful if it gets implemented by systems vendors and
utilized by network operators.
Getting system vendors to implement OAM functionality in their products
means making it straightforward to implement in ethernet designs. There
is a large amount of existing practice which will be levereged. OAM in
Frames is intended for a straightforward firmware implementation.
Getting carriers to utilize the facility means providing useful
capabilities in a form they can integrate into their networks. We need
to ensure that the information carried by OAM is useful for operation
of a carrier network, and can be described using the terminology familiar
to carrier environments.
> 9) Standards acceptance and ethernetishness. Some claims have been made
> that some techniques are more 'Ethernetish' than others - which to me
> means that the transport fits within the meaning of Ethernet better - so
> what are the main attributes of Ethernet and does this proposal fit
> better within them than others?
Ethernet is a packet switched network. Frames are switched to their
destination based on an address within the packet header. Demux of multiple
data sources is done based on an ethertype/SAP. No connection setup is
necessary.
Frames are the basic service provided by an ethernet network. Frames
are used for all functions on an ethernet, from resolving addresses to
data transfer to managing the infrastructure.
Placing OAM in frames means it will fit easily into the evolutionary
path of ethernet. It will work with existing Ethernet standards, and it
will fit easily into future Ethernet developments.
> 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)?
I believe that those configuration parameters necessary to begin
operation
of a particular type of PHY should be handled by that PHY. For example,
assignment of time slots on a PON must be done before the link can operate,
and are best done by a separate protocol designed specifically for the PON
environment. Similarly for Copper, if any negotiation needs to be done for
constellation sizes, symbol rates, interleave factor, etc it is best done
as part of an negotiation process between the PHYs.