[EFM] Re: openaccess issues ...
> I am trying to sting together some interesting topics for the
> March meeting to deal with unbundling fiber, open access for
> services (with a revenue stream that works for the owner of
> the infrastructure/transport/facility,
> call it what you will, straight billing and revenue share),
> and a technical proposal that can demonstrate both technical
> suitability (hence broad market acceptance), and a
> comparatively low cost of implementation. We will also try to
> address the OAM transport wars and the subject of QoS. Other
> than that we will have very little to say :-). I think the
> March meeting will be one of the most critical in the history
> of EFM. Hope you can be there.
Bob, others,
I've been researching these issues for quite a bit of time already. We
have open access on ADSL and Cable Modem in Canada that is quite
advanced in the regulatory circles. I would encourage that we hold a
CC: based discussion on that. My personal view is that the closest that
FTTH stays to opening the actual support structures for fiber, the
better. Then, issues grow more complicated the higher up in the
protocol stack. Opening up the OSP, then opening up VLANs, then opening
up at the IP routing layer, etc. It is my hope that groups such as the
FTTH Council will begin to focus on these issues.
With regards to EFM, I know that we will come under fire very quickly if
we don't stick to issues with defining open access requirements that do
fall within the system's view of EFM. We will quickly be told that
those are not PDM issues and that therefore they should be discussed
elsewhere. However, we do have systems problem that are not being
addressed elsewhere, and would believe that the standard would benefit
from involvement of EFM participants.
For example, I believe that we have significant issues associated with
managing VLANs (i.e. how do you make an IP Phone on CPE port 1 go to SP1
and a PC on CPE port 2 go to SP2, etc). As a result of a very
interesting meeting that I held yesterday with specialists in IPv6, I am
now suspicious that we will have another significant issue with the
practical payload size available to the application layer inside an EFM
packet, once all of the desired features are actually put to use in an
EFM system.
Bottom line: open access considerations in EFM could open up issues
related to physical layer systems issues, data-link layer systems issues
& network-layer systems issues. Even access by other SP's to actual OAM
frames is important. OAM in frames would be so much better from the
perspective that it could traverse the complete EFM system, from the
actual IP phone to the service provider (this brings up the issue of LLC
for OAM once again). Why shouldn't service providers be allowed to
monitor for link failures across home LANs?
A quick overview of the actual IPv6 stack will show that once IP
tunneling is in place, IPSec is used & routing extension headers are
used for constraint-based routing by Source Address, the actual
remaining payload size for IP applications inside an Ethernet frame will
be of a few hundred bytes instead of the 1300+ Kbytes that we're all
used to. At the risk of being reprimanded for bringing up the issue of
jumbo frames, I would share my belief that for us to duck away from
dealing with these issues (from a system's view of EFM) would not do any
good to the long-term market potential of the standard either. Just to
remind people, whereas IPv4 can support packet sizes of up to 65 Kbytes,
IPv6 can support packets up to 4 Gbytes, a far cry from what's possible
with Ethernet today.
We must not avoid dealing with these issues in EFM, however, we would
certainly aim to prioritize and focus.
-=Francois=-
f.menard@xxxxxxxxxxxxxxx
819 692 1383