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

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




At 16:48 05/09/01 -0700, Geoff Thompson wrote:
>[Date: 09/06/2001  From Seto]
> >This brings up the much uglier issue of discovery, also a topic that has
> >always been outside the scope of 802.3.
> >If there is going to be a bridge or router at the demarc then there will
> >have to be a discovery process that effectively logs the MAC address into
> >the service provider's system. The service provider won't be able to
> >Ping/Echo the box until it knows the MAC address.
>
>I disagree with your presumption that service provider need to
>know the MAC address of each demarc.  (...)

I have some comments about the discovery process. I'm not sure if it should 
be considered out of the scope of 802.3ah. Depending on the protocol, it 
may be needed to include some provisions in the standard, specially for EPON.

The basic options are:

1. Keep records of every MAC address in the network. That's allow for more 
control. In fact, it may be needed for shared media technologies (such as 
EPON), as a way to uniquely identify every unit into the same segment. 
Depending on the details of the protocol, there should be some provisions 
at the lower levels to make discovery easier.

2. Accept any MAC address, and control the connection at the upper layers, 
preferably using a 'self provisioning' approach. I can envision this being 
used in point-to-point networks, both copper and fiber based. It may be a 
bit more complicated to implement on PONs, but it may be possible; I 
haven't gave much thought to it yet. Anyway, the advantage is that there is 
no need for any specific provision in this case.


Now some generic rants about the discovery... we have some experience with 
the two methods described above. We have a sibling company that provides 
cable modem services, and as such, uses DOCSIS and DHCP. They keep records 
of MAC addresses in the management system, that are in turn associated with 
the 'service profile' of the user. If you want to bind the service 
physically to one piece of equipment, fine, but that's costly, and I'm not 
sure if it's worth the cost for large networks. The problem is that, if the 
customer changes equipment, it will not work until you reprovision the 
service. This is a radical departure of the 'self provisioning' vision that 
most companies would love to adopt. For instance, the DSL+PPPoE combination 
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 this 
implementation.


Carlos Ribeiro
CTBC Telecom