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: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] 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
|rrg@irtf.org
|http://www.irtf.org/mailman/listinfo/rrg
|