I have replaced the original Ivip-arch ID with a freshly written version 03. This is completely up-to-date and should be easy for RRG people to read without much head-scratching:
http://tools.ietf.org/html/draft-whittle-ivip-arch-03 This is 2 or 3 hours reading - 25k words, 61 pages of material, not counting TOC, references etc. Please don't complain about it being long. We are deciding how to upgrade the world's biggest and most significant IT system. This is 40% shorter than the previous version. This ID gives a good account of all aspects of Ivip, with goals, non-goals and the architectural choices which lead to Ivip. This is for IPv4 and IPv6, with encapsulation and its PMTUD problems, and with alternatives to encapsulation. It also covers mobility. This is the sort of scope a scalable routing proposal should have. If you paid good money for one which doesn't go this far, I reckon you should be entitled to a refund! The TOC follows my signature. I have also updated the other two IDs - on the fast-push mapping distribution system and on the Modified Header Forwarding arrangement for replacing encapsulation in IPv4 (which requires a modest upgrade to DFZ router FIBs). http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-02 http://tools.ietf.org/id/draft-whittle-ivip-etr-addr-forw-00 - Robin 1. Introduction 2. Goals IPv4 and IPv6 Portability, multihoming and TE for billions of end-user networks Modular separation of the control of mapping from the core-edge separation architecture itself Simple ITRs and ETRs with little or no communication between them Maximise the flexibility with which ITRs and ETRs can be located Mobility Elimination of encapsulation and PMTUD problems No requirement for new host functionality Full benefits to all adopters Business incentives to deploy new infrastructure Maintenance of existing levels of security and robustness 3. Non-goals Complete core-edge separation is not required Mapping changes need not be free of financial cost No attempt to cope with partially reachable ETRs No attempt to avoid all the mapping data being stored at any one location It may not be possible to completely eliminate unfair burdens No attempt to mix IPv4 and IPv6 Not Locator - Identifier Separation 4. Architectural Choices Core-edge separation rather than elimination Core-Edge Elimination (CEE) architectures Core-Edge Seperation (CES) architectures Local query servers Real-time mapping distribution SPI address management IP in IP encapsulation MHF initially or in the long term to avoid encapsulation and PMTUD problems Outer header address is that of the sending host IPTM (ITR Probes Tunnel MTU) PMTUD management 5. Architectural Elements ITRs Types of ITR and their addresses DITRs - Default ITRs in the DFZ Modified Header Forwarding - MHF-only ITRs Encapsulation and PMTUD management Mapping lookup and caching ITFH - ITR Function in Host ITRs auto-discovering local query servers ITRs regulating their advertisements ETRs In servers or dedicated routers ETRs in ISP networks ETRs at the end-user network site MHF ETR functionality - EAF and PLF ETR functionality for encapsulation QSDs - full database query servers Placement in ISP and end-user networks QSD initialization and reception of mapping updates Responding to queries Sending mapping updates to ITRs and QSCs QSCs - caching query servers FMS - Fast-Push Mapping Distribution System MHF - Modified Header Forwarding EAF - ETR Address Forwarding for IPv4 PLF - Prefix Label Forwarding, for IPv6 TTR Mobility _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
