Re: [rrg] Proposals which match rrgarchitectures.html

Hey Bill,

On Tue, 2008-12-30 at 22:07 -0500, William Herrin wrote:
> If I correctly understand APT (please correct me if I get it wrong),
> the default mappers contain ITR functionality. Packets sent to them
> are encapsulated and sent towards an ETR.
> 

So far so good.  Each ISP should have 1 or more default mappers.

> Next, you layer on the TRs which accelerate the process. Packets to be
> encapsulated go to the TRs first where a fast, small cache of
> destinations is consulted. When the TRs encounter a packet they don't
> currently know how to map, they forward it to the default mapper. In
> addition to encapsulating the forwarded packet, the default mapper
> installs a map entry in the TR's cache so that it can handle
> subsequent packets with the same destination on its own.
> 

Right.

> The default mapper keeps track of the caches in the specific TRs that
> it serves. When a map affecting one of the cached entries changes, the
> default mapper updates the TR's caches with the new map. Because the
> mapper is authoritative for the specific TR's entire cache, it gets
> around the change notification failure problem from
> http://bill.herrin.us/network/statechange.html . TTLs and other
> techniques for expiring the cache aren't necessary; the default mapper
> handles it.
> 

Actually, in older drafts of APT, default mappers did not keep track of
the cache state in TRs.  We thought this added too much additional
complexity to the default mappers.  The TRs used TTLs to expire stale
mappings.  

However, since default mappers are only responsible for their own TRs
(at most the # of TRs in the ISP), it may not be out of the question to
do what you described.  When we begin implementation and simulation of
APT, we will get a better idea of how much a default mapper can handle.

> Although the TRs and their default mapper are physically separate
> pieces of equipment and may not be at the same physical location, they
> are logically one ITR node which doesn't function without both
> components.
> 
> If that description is accurate, the heart of the system is the
> default mappers which exist in every APT network. How do the default
> mappers get those full maps? Periodically (A2a) with the expectation
> that the default mapper must determine which remote ETRs are presently
> successful or continuously (A2b) as they change to match the currently
> functioning network topology?
> 

Well, we do A2b for MAPPING changes, meaning a change of the set of
providers serving a customer, or a TE preference change.  However, link
state dynamics(reachability status of provider to customer) do not cause
mapping updates.  Failures are handled using data-driven notifications,
where only parties attempting to send data through a failed
customer-provider link are notified of the failures.  See section 6 of
http://tools.ietf.org/html/draft-jen-apt-01 for a deeper explanation of
what I'm talking about.

Of course, we modify APT as we gain a better understanding of the
problem and solution space, so the above isn't set in stone.

- Dan Jen

_______________________________________________
rrg mailing list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg