Hi Robin, On Mon, Jan 25, 2010 at 5:53 PM, Robin Whittle <r...@firstpr.com.au> wrote: > > Not necessarily. The ITR function could be in the sending host > (Ivip, not LISP, except LISP-MN), or in any other router. The packet > from host-B to host-A doesn't necessarily go back through, or even > near, the device which performed the ETR function on the first packet. > > If host-A is on a conventional address (ordinary PI or PA) then > there's no need for an ITR anyway. If it is on SPI address (Ivip - > or for LISP "EID" space) then at some stage the host-B to host-A > packet will be encapsulated by an ITR. In Ivip, if there is no ITR > function in host-B, then the packet may be processed by an ITR > function in the host-B's network (perhaps the same device which did > the ETR function for the first packet) or a router in the ISP network > (likewise - maybe the ETR was in the ISP network, rather than > host-B's network). If there is no ITR in that path, then the packet > will go out of the ISP and be forwarded to the nearest DITR (Default > ITR in the DFZ - which in LISP is called a Proxy Tunnel Router). > That encapsulates the packet and tunnels it to the correct ETR. >
Ok, got it. An ETR has never a cache but for the returning traffic you might need an ITR (could be most likely the ETR for the initiating session). So, yes, there is no cache for an ETR - the cache is always on the ITR. > >> Think >> there needs to be a cache table so that this ITR can assemble the >> outer, UDP and LISP headers - the host can not know those headers >> unless it is upgraded and if the host is upgraded it is no longer a >> full blown CES solution. > > ITR functions are much the same in principle no matter where it is > done. The ITR caches mapping information, and if it doesn't have > mapping for a micronet covering the destination address, say of > host-A for the second packet in this example, then it sends a mapping > request to get this. > > In Ivip, the ITR buffers the packet for a few tens of milliseconds at > most, since the mapping comes quickly and reliably from a local full > database query server, such as in the same ISP or end-user network. > > With LISP-ALT, the ITR drops the packet and sends a request into the > global ALT overlay network, directly or via a local Map Resolver. > The reply comes back - via the Internet. Since this is a global > network and the path in the ALT system could be longer than an RTT > across the the Earth and back, the ITR does not buffer the packet. > Instead, once it has received the mapping (which might take a short > time, but will often be 400ms to maybe a second or so - assuming no > packets are lost) then whenever the host sends another packet to the > same destination, the ITR encapsulates that one - and it is tunneled > to the ETR. > > An ITR function may be in the same box (a router or a server) as an > ETR function, but the two functions don't communicate in Ivip - or as > far as I know, in LISP. > > Yes, agreed and that what is what I was referring to - an ITR in front of a popular server (that might be an ETR for the initiating traffic from a client). But I stop using that term, instead "ITR in front of a server" is the term. Then to the issue. If you take the CES functionality to the xDSL routers you will get a lot more entries on the ITR in front of a server at a popular site. The reason is that the xDSL prefixes are quite well aggregated in today's DFZ. But once you apply the CES solution on the xDSL router it will carve up the aggregated (PA) prefixes on the ITR in front of popular servers. E.g. if an ISP uses today a /20 aggregate for their xDSL connections and the residential users are allocated /29 prefixes for their networks. If the residential users would deploy a CES solution in their xDSL routers you will have lot more entries in the ITR in front of popular servers - in the current architecture you have only /20 entry in the FIB but in the CES architecture you can't predict how many entries you will have in the FIB - it depends if, when and how many xDSL users are accessing your server. And if your site is very popular do you need more FIB entries than today's router do have, just in case the CES solution gets very popular and deployed very close to the edge? This is my concern and the reason why I think a CES solution also should include a CEE approach. Or do I still miss something? -- patte _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
