[EFM] RE: Discussion of higher layers
All,
A lot of bandwidth has been consumed in discussing issues which are beyond
the scope of 802.3. Although these issues are important in framing a
complete network design, which in turn can throw up requirements for the
physical layer, it is not as if these issues have never before been
addressed before. People who have been active in either ANSI T1E1 or the DSL
Forum will recognise the same discussions that they had some years
previously!
This is clouding the central objective of this group, which, as I understand
it, is to define Ethernet connectivity between a Customer Premise LAN and
some remote network. Provided that: (1) at either end of this link a
standard 802.3 port is presented and (2) this link provides at least a
simple repeater function, then the objective will have been met. All other
issues are implementation details which will be driven by the particular
service offerings and the needs of the contracting parties. There will be no
one model which will fit everyone. It is likely that bridging and/or routing
functions would be integrated into systems as would multiplexing and the
whole spectrum of OAM&P functions. However, such service bundling would be
in addition to the base end-to-end Ethernet function.
MAC & higher level processing of traffic is properly the remit of 802.1,
IETF, etc. But what about line codes & data encapsulation? Should EFM
develop their own? My view is that this would not be a good idea. In the
case of copper links, it is simply too late as well as unnecessary. There is
nothing that Ethernet needs that existing & upcoming DSL technology cannot
provide. If EFM were to define an end-to-end 802.3 service model, this could
then be offered to the DSL Forum for inclusion into their specs. I cannot
speak on matters optical, as I am not involved in this sphere, but I suspect
the same approach would probably be the most efficient: i.e. present a
service requirements spec to the specialist groups that are developing
particular physical layer technologies.
Malcolm Herring
Tut Systems