RE: [EFM] EFM P2MP - Discussion of higher layers
I don't see anything in your examples that warrants any additions to the
standards for the protocol stack at the MAC layer or below.
OAM: your scenario is an excellent example of why you want your OAM
diagnostics/probes to send their data in a manner as close as possible to
the end-user's traffic: how are you going to check the level of service
being obtained by the user data if your probes are using a completely
different set of channels,schedulers/queues etc.????
Intellectual property: I think this is a red herring - encryption is far
better left as an end-to-end thing between the application server and the
client; authentication is usually less hard computationally but, still,
you'd want to outsource this from any network infrastructure devices to a
separate server (see e.g. EAP, RADIUS or 802.1X). There's no way you want to
build this type of complexity into the intermediate network. It is possible
there is new work needed on authentication on shared networks in general but
I don't see anything 802.3-specific there.
Leased-line emulation: there's been a lot of theoretical and practical work
on this at IETF ("Expedited Forwarding" behaviour in Diffserv for example -
check out some of the literature from Van Jacobson and others e.g.
One of the simplest ways of building this is with a rate limiter at the
ingress to the network and simple priority queueing within the network. Rate
limiting and priority scheduling can be done at whatever layer you choose
but they do not need new standardisation at any particular layer. I'd
challenge you to come up with a simpler method than this for legacy service
[mailto:email@example.com]On Behalf Of John Limb
Sent: Wednesday, September 05, 2001 8:24 AM
Subject: [EFM] EFM P2MP - Discussion of higher layers
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.