[EFM] EFM P2MP - Discussion of higher layers
Carlos, Ryan, Fletcher and the group,
This group has spent a lot of time debating very broad questions about
where we are going, and to many this may seem like a waste of time. After
all, all we want to do is define a MAC protocol and associated PHY layers
for P2MP service. However, we all come to this from very different points of
view. Nevertheless, there seems to be some convergence. Let me outline why I
think it is important that we discuss broad functional requirements that go
well beyond what we are trying to standardize.
Firstly, in standardizing a protocol that will be largely used to provide
service to residential and small/medium business 802.3 is going well beyond
its usual user base, and the user is very different from the customer (the
service provider). We would like to see the 802.3ah standard widely
deployed, but it will be the service providers (customers) like ILECS, CLECs
and MSOs that will make that happen. That is why I listen very carefully
when they tell us what they think they need. The traditional 802.3 service
has been a fast, best-effort, packet service. Other higher layer services
have been built on top of that.
ILECs need a fat pipe that will enable them to provide a mix of services to
the home including the usual voice, data and video. This will enable them to
compete with MSOs that currently have medium-to-good video/voice/data
laboriously executed on analog plant with higher than desired OAM costs.
802.3ah can do for the residential customers what it did for business
customers if it provides a broadband digital pipe that supports the services
that the residential service providers desire. This means that the hooks
must be in the MAC and PHY layers that will support the services that are
implemented at the higher layers. But what are these hooks? I don't exactly
know, but I think we can find out what they need to be by trying to
understand the higher layer services that will need to be provided, and this
understanding is obtained by listening to the needs of the service
providers.
Perhaps I can give a couple of examples. A first example might be OAM. The
service providers express a strong need to be able to control very tightly
the level of service that a user receives. (Receiving too good a level of
service can be a real problem!) This gets to the core of whatever grant
mechanism is used. Remote fault detection, isolation and repair is extremely
important and might indicate the need for hooks in the Phy and MAC layers.
Another example concerns the protection of intellectual property that is
distributed in the form of video and music. This is of incredible concern to
the movie industry and any service provider that distributes this type of
content. How is this content best protected? I don't know. But it may
indicate that some link level security is required, or maybe it can all be
handled at a higher layer. But we need to know.
A third example could be support of legacy services such as DS1, DS3 and
G.711 voice stream. Again, perhaps these can be supported without any hooks
in the lower layers but on the other hand a simpler solution may require
some control over jitter in a DBA scheduler.
In summary, to make sure that we come up with a MAC/Phy solution that
service providers will be able to use we need to consider the services that
they want to provide and make sure that if they need hooks at the lower
layers for cost effective implementation, that we provide them.
John Limb
Tel. 678 475-3241
e-mail limb@xxxxxxxxxxxx