Robin, Thank you very much for your suggestion. However, section 3.1.3 (and, for that matter, all of section 3.1) is much more general than section 3.3.1.4. I believe that those two techniques are covered quite adequately there.
Regards, Tony |-----Original Message----- |From: [email protected] [mailto:[email protected]] On |Behalf Of Robin Whittle |Sent: Tuesday, February 17, 2009 10:56 PM |To: RRG |Subject: [rrg] draft-irtf-rrg-recommendation-00 - |Modified-Header Forwarding(MHF) | |Hi Tony, | |I fully support the recommendation that we spend another year |devising our final recommendation. | | |Here is some suggested text to add after "3.1.3 Map & Encap". | |The two MHF techniques are: | | ETR Address Forwarding (EAF) - for IPv4 (A4g) | 30 bits for the ETR address | http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw | | | Prefix Label Forwarding (PLF) - for IPv6 (A4f) | 19 or 20 bits to identify the BGP advertised prefix of the ETR | http://www.firstpr.com.au/ip/ivip/ivip6/ | | | Regards | | - Robin | | | |3.1.4 Map & Forward with Modified Header Forwarding (MHF) | |An alternative mechanism to Map & Encap retains the mapping system |and overall structure of tunneling the traffic packet across the DFZ |to a tunnel endpoint device at the RLOC address - which forwards the |packet directly to the destination network. Instead of |encapsulation, Modified Header Forwarding (MHF) alters the IP header |of the original packet to include sufficient bits to specify part or |all of the RLOC address of the tunnel endpoint device. That device |restores the original state of the IP header and forwards the traffic |packet directly to the destination network. | |Strategy A4f (below) provides enough bits in a modified IPv6 header |for routers to forward the packet to the ISP network which contains |the RLOC device. Strategy A4g encodes a 30 bit RLOC address into a |modified IPv4 header so the packet can be forwarded all the way to |the tunnel endpoint. | |The primary advantages of these techniques are elimination of |encapsulation overhead and of the Path MTU Discovery problems which |are inherent in any encapsulation-based tunneling solution. | |The primary disadvantage is the need for all DFZ, and some internal, |routers to be upgraded to recognise the altered IP header format. |For IPv4 an additional constraint is lack of support for fragmented |packets or fragmentable packets longer than some constant, likely to |be somewhat less than 1500 bytes. However, similar constraints may |apply to any system which adequately manages the PMTUD problems |caused by encapsulation. | |These techniques could be used by adapting any Map & Encap |architecture which does not need to carry further bits of information |with the traffic packet and which does not require the tunnel |endpoint to be able to determine which device tunneled the packet. |For such an architecture, MHF could be used as a more efficient |long-term alternative to encapsulation. | |Alternatively, if the routers could be upgraded in time for the |introduction of the scalable routing solution, these techniques could |be used from the outset, eliminating the need for development of |encapsulation techniques and of solutions to the resultant PMTUD |problems. | | | | | | | | | | | |_______________________________________________ |rrg mailing list |[email protected] |http://www.irtf.org/mailman/listinfo/rrg | _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
