Hello Xiaohu, You proposed some load-sharing techniques:
> LISP+CONS and ALT are based on tree-hierarchy overlay, and the > initial traffic will be allowed to travel along the overlay in > order to avoid initial packets loss. However, this approach not > only results in a longer forwarding path but also a high > forwarding pressure on the highest-level nodes (like honey > point). The initial traffic volume is not in the same magnitude > with the query messages in DNS hierarchy. Traffic concentration at the highest-level nodes could be reduced by having having all ALT routers fully meshed at a particular level - beyond which there would be no need for higher levels. For instance, 221 ALT routers (or multiple routers for load-sharing and redundancy) each aggregating one of the IPv4 /8 prefixes. (221 is the 0 to 223, not counting 127, 10 and 0, which is perhaps not suitable for traffic). > APT and ivip, based on the anycast idea, not only avoids the long > path and large-latency for the initial packets but also share the > initial traffic pressure among the different default mappers. > However, they are not so scalable to support host or micro-net > granularity. I will write another message about why I think the mapping database will never be so big that it would be impractical to have multiple copies of it all over the Net. So I think ALT etc. (global query server systems) are not needed at all. APT and Ivip share the encapsulation load between hundreds of thousands of ITRs all over the Net, though at this stage APT doesn't have an "anycast ITRs in the core" / "Proxy Tunnel Router" approach to handling packets from networks without ITRs. Your proposal aims to spread the load of encapsulating traffic packets at any one ITR location between multiple ITRs. > Could we consider some tradeoff between these two approaches? For > example, replace the default mapper with multiple mappers which > are responsible for different address-prefix blocks in APT and > ivip, or allocate multiple highest-level nodes in CONS or ALT, > which are responsible for the same address block, to many > different network locations. Ivip provides for load sharing amongst ITRs by having one ITR handle one subset of the BGP-advertised prefixes while other ITRs handle the remaining subsets. This is not mandatory - most ITRs would handle all these prefixes. However, it remains an option for spreading load at busy sites. The idea is that an ITR would advertise, either in the internal routing system or in the global BGP system, just those prefixes which it handles. These prefixes are called "Ivip Mapped Address Blocks" in the current ID. They are known as "MABs" - "Mapped Address Blocks" in my attempt to define some terminology: http://psg.com/lists/rrg/2007/msg00533.html http://psg.com/lists/rrg/2007/msg00535.html http://psg.com/lists/rrg/2007/msg00719.html This has been part of Ivip since July (the 01 draft is the same as July's 00): http://tools.ietf.org/html/draft-whittle-ivip-arch-01#section-1.8 In this introduction, I assume each ITR handles the full range of IMABs (Ivip Mapped Address Blocks) in the Ivip system. However, to spread load over multiple ITRs in a single location, several could be configured so they each cover a fraction of the total Ivip-mapped address space. http://tools.ietf.org/html/draft-whittle-ivip-arch-01#page-33 Where a single large range of contiguous addresses is for some scaling reason handled with separate database dumps and update streams, it should be divided into separate IMABs. This increases the number of BGP advertised prefixes, but may be justifiable, for instance within a large (eg. /8) prefix of IMIP (Ivip-Mapped IP address) space, so that ITRs can load share by each handling a subset of the entire /8. http://tools.ietf.org/html/draft-whittle-ivip-arch-01#page-65 Also, by splitting something big like a /8 into four or 16 smaller IMABs, there is only a slight extra burden on the global BGP routing table, but the process of booting, downloading IMAB-DBD files, buffering a stream of US-IMAB updates, etc. can be done in smaller chunks, including especially smaller allocations of RAM inside the ITRD or QSD. This would also facilitate finer control of load balancing when a single ITRD couldn't handle the traffic in one location, and several ITRDs were used there with different IMABs for each one. As far as I know, APT has no such provision. I think LISP's Proxy Tunnel Routers (applicable to ALT or NERD) could be operated as just described for Ivip - each handling a subset of the BGP prefixes which are for EID address space. NERD ITRs request mapping data and updates themselves. So a NERD ITR handling a subset of the total EID space would only request the appropriate subset of mapping updates. A full database Ivip ITR normally gets the full feed of mapping updates. There could be some facility in the mapping distribution system (currently called the "Replicator" system) to send only packets concerning this subset. It would be tricky to split up the address range for which an Ivip QSD (full database Query Server) was responsible, because that would require the requesting devices (caching ITRs and caching query servers) to know which range of addresses each of the multiple query servers were responsible for. There could be two or more linked QSDs, each receiving queries, but each having only a subset of the mapping database - passing queries to the a nearby QSD for the addresses they don't have the data for themselves. This would be possible, but there would have to be a truly massive amount of mapping data to make it worth the trouble. - Robin http://www.firstpr.com.au/ip/ivip/ -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
