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

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





Summary if you want to skip this long message:

Carlos states some excellent requirements of which any engineer of an
public Ethernet network ought to be aware.  Existing Ethernet
mechanisms (SNMP MIBs for Ethernet switches) already allow these
requirements to be met.  If 803.2ah maintains those mechanisms,
Carlos' requirments can be met.  The use of PPPoE is not required to
meet these requirements.

On Wed, 05 Sep 2001 23:55:55 -0300  Carlos Ribeiro wrote:
> 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.

key:
MAC = Media Access Control -- as used here [Ethernet] MAC [address]
IP = Internet Protocol -- as used here, Internet Protocol [address]
CO = Central Office, the location of the Service Provider's equipment
CPE = Customer Premise Equipment
switch = as used here, [Ethernet] switch
DHCP = Dynamic Host Control Protocol
ESLAM = Ethernet Subscriber Line Access Multiplexer

Carlos;

	There was quite a discussion on this topic on the nanog
(archive: http://www.merit.edu/mail.archives/nanog/) and dhcp-server
(archive: http://marc.theaimsgroup.com/?l=dhcp-server) mailing lists
between June 19th and 28th of this year.  Some thoughts:

1) The existing protocols allow MAC addresses and MAC <=> IP <=>
   customer bindings to automatically be captured in a central location.

2) Personally, I think that it is dangerous to design a network
   without such capture.  I think the service provider (SP) would have
   great difficulty reaching the excellent requirements you stated:
    a) safety
    b) security (of which privacy
    c) reliability
    d) performance

Unless the SP has the current and historical MAC <=> IP <=> Customer
bindings, it is difficult to:

1) Maintain safety by being able to respond to law enforcement subpoenas,
2) Maintain security (privacy) by responding to attacks on and from
   customer equipment,  Note that attacks from customer equipment
   frequently is the result of hijacking that equipment.
3) Maintain reliability by being able to detect and troubleshoot problems,
4) Maintain performance by being able to meter and monitor flows to
   identify potential bottlenecks.

Again, I view 802.3ah as a CO <=> CPE protocol.  If 802.3ah maintains
the same information as the base 802.3 protocols, it will not be
necessary to take any action to allow the above to happen.
Traditionally, central systems have captured and stored MAC addresses.
I think all switches do this now.  IPs are generally supplied by a
DHCP server and the DHCP protocol is easily monitored by the SP.  This
information can be stored by the SP.

So it is possible to maintain the self provisioning nature of the
network, and still have the MAC <=> IP <=> Customer information at
your finger-tips when Code Red on Steriods hits.  When a customer
plugs in a device, the ESLAM reports the customer's device MAC when it
sees it.  The DHCP server records the MAC <=> IP binding.

I would think it would be very difficult to do the above manually.
However, at both these points, an automated system could insert this
information in a database.

As for cost and scalability: it seems to me that these systems should
be cheap and scalable.  There is already a high quality, Open Source
DHCP server produced by the Internet Software Consortium which has all
the mechanisms necessary to store MAC <=> IP information in a
relational database (see http://www.isc.org/products/DHCP/).  The MAC
customer information should be available via an SNMP query agains the
ESLAM.  

As Carlos pointed out, PPPoE is another mechanism for maintaining the
same mapping.  However, some people regard this as a heavy-weight
solution that imposes burdens on the customer and SP.

regards,
fletcher