RE: [EFM] Discovery (it was OAM...)
Carlos,
Thank you very much for the clarification. It's nice to hear it from
the carrier's perspective. I wonder have you heard the big stir about
SBC's decision to go with PPPoE? Please check out:
http://www.internetweek.com/newslead01/lead080201.htm
And you are right, this is out of scope of this forum and maybe we
should bring the discussion off-line. I will send you separate email
regarding this.
-faye
-----Original Message-----
From: carlosal@xxxxxxxxxxxxxxxxxx [mailto:carlosal@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, September 06, 2001 11:52 AM
To: Faye Ly
Cc: Francois Menard; Carlos Ribeiro; Geoff Thompson;
seto.koichiro@hitachi-cable.co.jp; stds-802-3-efm@ieee.org;
carlosal@xxxxxxxxxxxxxxxxxx; Dolors Sala
Subject: RE: [EFM] Discovery (it was OAM...)
Faye,
Warning: this message is not directly related to EFM, but it explains
the
particularities of the PPPoE model, that is a very popular way to deploy
data services for DSL and cable networks. It is a potential application
for
the EFM solution.
-----
The original message regarding PPPoE was mine. It has nothing to do with
OAM at the link level; it is used to provision the connectivity between
the
end user and the service provider for IP services,such as Internet
access.
It's a very good way to provision services in the DSL world. In fact,
many
DSL providers have turned to PPPoE as the standard solution for
connectivity. One of the advantages of the PPPoE solution for DSL is
that
it allows to implement a tunnel traversing different technologies:
Ethernet
inside the user home, ATM into the DSL network, with the termination
being
handled by a special aggregation box with ATM interfaces.
The reason why I cited PPPoE is that it is a very good solution from the
service provider standpoint. It allows to stablish dynamic connections
with
very low overhead (a few extra bytes per packet, tipically less than 3%
of
the payload). These connections make easy to implement a flexible
service
selection paradigm, where the user can chose the ISP at time of
authentication.
Looking strictly from an engineering standpoint, the solution may seem
awkward. After all, why tunnel another L2 protocol over the Ethernet
network? After working with several types of access networks in the past
few years, I can tell you that no other technology is best suited for
mass
deployment. The amount of configuration is negligible, the flexibility
is
excelent, and the cost is very, very low. The termination box is
normally
able to to a lot of valued added services, including content delivery,
firewall, bandwidth management, and so on. Compatibility is not an issue
either, as all the basic requirements are fulfilled by open standards
and
protocols.
In short, the use of a 'virtual' L2 topology makes the network much more
flexible. It does not matter if the customer is connected through DSL,
cable modem, dial up or fiber. The tunnels can be stablished directly
between the endpoint and the service management gateway, using either
PPPoE, PPPoA, or even L2TP, as all the protocols are closely related.
(on the other hand, the proposed alternative - 802.1X - doesn't quite
cut
it; it's bound to the Ethernet world. The 'PPPoX' familiy makes
interoperability easier)
Let us look at the issue from other sides; there are some alternatives,
such as the flat network with DHCP, and fully IP-based networks.
- The flat network has some serious problems with scalability and
security.
You can solve this problems by breaking the network into smaller blocks.
In
fact, if you keep breaking the network until you have a 1:1 relation
between the endpoints, then the scenario becomes very similar to the
PPPoE
solution.
-The full IP solution looks nice on paper, but it does have serious
limitations. The IP address allocation is difficult to manage, and it's
difficult to segregate the traffic of every individual customer to
guarantee specific service requirements. Tipically, the intelligence is
scattered all over the network in several routers, making it much harder
to
manage. The solution in this case is to deploy big 'access routers' into
the network, and to connect every user to a dedicated interface. Again,
going this road takes us exaclty to the PPPoE scenario again.
Of course, there are still hot debates about the relative merits of each
solution. For example, PPPoE is very good for provisioning Internet
access
services, but it's not well suited for broadcast/multicast based
services,
such as video delivery; it simply does not scale very well. My opinion
is
that the basic EFM design should not assume that any of the solutions
above
is going to be adopted as the standard solution for service provisioning
anytime soon.
Carlos Ribeiro
CTBC Telecom