Cell Relay Archive

[albert.e.manfredi@boeing.com]

In article <37665819.12870226@news.demon.co.uk>,
  charlesn@hn-networks.co.uk wrote:
> Does anyone have any material or know of any web sites with
> information regarding to the scalability of MPOA. I deliver ATM
> training courses and look at both MPOA and the use of MPLS over ATM.
> More than once I have been asked about the scalability of both models.
> I think that I understand the way in which an MPLS network may scale
> based on following a traditional routing model, however I am not so
> sure about MPOA.

Charles, I looked in the IETF ION working group's Internet Drafts list
to see if it was still there, but it wasn't. Back in the days when the
Next Hop Resolution Protocol (NHRP, RFC 2332) and tag switching were
being hotly (and humorously sometimes) debated, I think it was
Grenville Armitage (Bellcore then, now Lucent) who wrote an I-D that
spoke to this. The scalability issue with MPOA is exactly the same,
since MPOA uses NHRP.

So what is the issue? It is that you are mapping the IP hierarchical
address into an ATM hierarchical address structure, but the two
hierarchies are completely unrelated. So you end up with very large
shortcut tables, in essence.

NHRP looks for an ATM End System Address (AESA) that matches most
closely the IP address. It looks to match the longest possible IP
prefix for that particular IP destination with an AESA, for two
reasons: (1) to stay within the ATM shortcut as long as possible,
bypassing the largest possible number of IP routers, and (2) to try to
prevent routing loops from occurring (in case the closest possible AESA
is still several hops away from the IP destination).

But because the IP and the AESA hierarchy are unrelated, the end result
is that you will potentially have very many different IP-AESA mappings,
even if some of the IP addresses have some of the hierarchy in common.
Example: if you are trying to reach a.b.c.d and a.b.c.e, you will not
necessarily be able to use an AESA that supports a route to a.b.0.0.
You might have to make two table entries, one for each IP destination,
servicing these through two different AESAs.

The ultimate poor scaling situation would be that the destination
address is a flat address space, like MAC, which would require an
exhaustive table. This is not as bad as that, but you can see that it
could approach that ultimate case.

--
Bert
manfredi@arl.bna.boeing.com


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.