Short version: Discussion of placement of ITRs closer to the sending hosts.
Why I think DITRs/PTRs will initially handle most packets and why ISPs will increasingly be motivated to install their won ITRs. Hi patte, You wrote: > finally got an understanding of CES, sorry for taking so long. Let see > if I got it right this time... > > For a conventional host A (PA address) -> CES enabled B host: Host A could be on a PI address too. > Actually the closer the ITR functionality (DITR/PTR) is to the xDSL > routers the better the cache scales, since most likely the residential > users access the same services and the cache will not grow that much. Yes. Generally speaking, the smaller and cheaper you can make an ITR, the more you can have of them, the closer they can be to the sending hosts and so the less mapping each ITR will have to cache and the fewer packets each one will need to tunnel. Ivip is the only CES architecture to have optional ITR functions in the sending host (ITFH). (LISP-MN mobile hosts have this option, but I think that this is the wrong approach to mobility. The TTR Mobility [1] architecture would work OK with LISP and would be far better.) If the sending host can have an ITR function added, and if it is: 1 - On conventional (PA or PI) or SPI space - not behind NAT, and: 2 - Has fast, reliable, low-cost access to one or ideally two full database QSDs. then it would be good to put the ITR function there. For Modified Header Forwarding (MHF) [2] to operate, all the routers, including DFZ routers between this new ITR location and all ETRs would need to be upgraded. For the rest of this discussion I will assume the ITRs use encapsulation rather than MHF. I will probably add an option for an ITR or ITFH (to be behind NAT. It would make a two-way tunnel to a caching query server QSC outside NAT, on a conventional address, and use keepalives to maintain the tunnel. Placing the ITR in the sending host typically involves no hardware costs at all. One minor disadvantage is that there are map query and response packets going back and forth, and occasionally a map update packet to the ITR. Also, the encapsulated packet is longer, and if the shortest MTU between it and the ETR is the PPOE link which a DSL modem uses, then this would result in slightly shorter packets being able to be sent by the sending host applications. I don't suggest putting an ITR function on a sending host which relies on a wireless link, such as a 3G link. Maybe it would be OK on a WiFi or WiMAX link which was consistently fast, reliable and inexpensive. With these caveats, the best place to put the ITR function is in the sending host. > The more CES enabled sites a DITR/PTR has to handle the more stress it > will put on the ITR cache - so here is a dependency between > geographically distributed DITRs/PTRs and amount of CES enabled sites. > The cache scalability is all about to get the DITRs/PTRs in optimal > places. When Ivip/LISP is first introduced, I think DITRs/PTRs will handle most or all of the packets. When an end-user network is using SPI/EID space (and so is using one or two ETRs) it will presumably also have an ITR somewhere. It may have the ITR in the same box(es) as the ETR(s) but it may rely on the ISP to have an ITR. It doesn't really need an ITR, since it could always let the packets to to DITRs/PTRs. Over time, as the CES architecture becomes more widely used, I would think that ISPs would want to introduce their own ITRs, partly to ensure their customers' packets which are sent to SPI/EID addresses are handled reliably, locally, rather than depending on potentially busy DITRs/ITRs. For any ISP which has ETRs in its network - or has any of its customers running their own ETRs, such as at their own home or office, using the the PA address which comes with the DSL etc. service - then these ISPs have some SPI/EID using customers. Presumably, some of their customers are going to be sending packets to these SPI addresses. The ISP doesn't necessarily need to provide an ITR, but by doing so, it avoids the expense of those packets going out to the DFZ to the nearest DITR/PTR and then coming back, tunneled, to the ETRs in the ISP's network. Over time, I would expect low cost ITRs made from ordinary servers and freely available software would be common in ISP and larger end-user networks. Also, conventional routers may be upgraded to do this, and new ones would probably have ITR functions built in. At the same time, host operating systems would either have ITR functions built in and optionally enabled, or be available as separate packages which could be installed. Any hosting farm would be keen to get ITR functions in each such host OS, since it has large volumes of outgoing packets, and a growing proportion will be to hosts with SPI addresses. In the long term, I expect DITRs/PTRs to handle a small proportion of packets - but at the start, I think they would handle most of them. If the DITR only handled MABs (Mapped Address Blocks - DFZ advertised prefixes containing SPI space) containing micronets which were mapped to ETRs in a certain area, such as Australia, then it would suffice to have the one or more DITRs for these MABs in Australia. However, the whole idea of a CES architecture is to enable these SPI (EID for LISP) addresses to be used anywhere. So in general, DITRs/PTRs need to be scattered around the Net, topologically speaking, to generally minimise the extra path length between any ITR and any ETR, and to spread the load reasonably evenly between them. > In a nutshell, CES is all about taking out the multi-homed PI > addresses from the DFZ - transforming them into PA-addresses (RLOCs, > which are aggregated) and provide a multi-homing solution for IPv6 so > it will not further expand the size of DFZ. This is part of it. I will write my attempt to summarise the purpose of CES in a separate message. > Thanks for your patient and education - my sincere apologizes for > being slow on learning. But is has been useful for me, sorry for > wasting yours and Noels time. I don't think it is a waste of time, since I guess there are a few lurkers who are also finding it hard to understand these things. - Robin [1] http://www.firstpr.com.au/ip/ivip/#mobile [2] http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/ _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg