Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Discovery (it was OAM...)


I am not sure about DSL + PPPoE.  In most of the DSL deployment cases
I know, DSLAM (headend) is using proprietary method and they require
CPE vendors to certified with them in order to claim
One vendor does so with a protocol based method.  Perhaps you can
clarify further how does DSL + PPPoE does the discovery?

DSL forum did try to come up with a standard using the OAM channel
as well.  Both cases require the DSLAM providing a station
management capabilities not only for discovery but also for other
things such as inventory.

For most of the cases involved in remote management I have seen, there
are generally two methods:

1. Use dedicated channel or circuit - cases like OAM channel or ILMI
circuit for ATM.
2. Use protocol based method - cases like mingle control frames with
data frames in the same pipe but different frame header. 

I suspect since EPON or point to multi-point Ethernet access network
does require some sort of registration and on-going bandwidth
we should probably consolidate the 'management channel' (for lack of
a better term) into one methodology.   In another words, IF CPE is
to register itself with the headend at startup, we can overload the 
registration with other inventory information to complete the discovery
as well.  

On the other hand, IF CPE is required to establish a channel with the
headend at startup for registration, it can also be used to complete 
the discovery.  Either case will work but I don't quite know where
DSL + PPPoE fit?


-----Original Message-----
From: Francois Menard [mailto:fmenard@xxxxxxxxxxxxxxx]
Sent: Thursday, September 06, 2001 7:39 AM
To: 'Carlos Ribeiro'; 'Geoff Thompson';
Cc:;; 'Dolors Sala'
Subject: RE: [EFM] Discovery (it was OAM...)

>most companies would love to adopt. For instance, the DSL+PPPoE
does not need to keep this kind of record, because all provisioning info

can be tied to the user login, making automatic configuration easier. Of

course, not all technologies and service models lend itself easily to

For example, this could be achieved using 802.1X authentication rather
than PPPoE, thus not requiring that end-users pay for another
encapsulation overhead if the volume usage is metered.  I can certainly
choose to pay for TCP/IP overhead on my own free will, but being forced
to pay for PPPoE overhead does not seem to be appropriate to me.
Fortunately, all DSL offerings that use PPPoE today seem not to feature
volume usage restrictions.