Docstoc

PowerPoint Presentation - Transmission of IPv4 packets over IEEE

Document Sample
PowerPoint Presentation - Transmission of IPv4 packets over IEEE Powered By Docstoc
					IPv4 over IEEE 802.16 IP CS
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-03



             Samita Chakrabarti
                 IP Infusion
              Syam Madanapalli
             Ordyn Technologies
                 Daniel Park
                  Samsung
                          Background

 WG LC comments addressed

 Issue from the last IETF
   – Major:
      • Default MTU - whether it should be 1500 bytes or less
   – Minor:
      • Editorial clarifications
            What Changed in rev 03

 Addressed major comments from Burcak Beser,
  Wesley George, Max Riegel and Keshav Chawla

 Finalized text on MTU choices based on IEEE
  feedback and working group discussions

 Added a few sections for clarifications; added
  thoughts on multicast packet handling at the appendix
                      Default MTU

 The following considerations were used to choose the
  default MTU value (suggested by AD, Jari Arkko)
   – difficulty of manual configuration
   – ability to raise/lower the values automatically
   – capability of 802.16 backhaul networks to handle larger
     MTUs (ipcs, ethcs, wimax and non-wimax)
   – ability or inability to determine what network you are in
   – inability of L2 devices to send ICMP messages
                          Default MTU
 New Text
   –   The MTU value for IPv4 packets on an IEEE 802.16 link is
       configurable. The default MTU for IPv4 packets over an IEEE 802.16
       link is 1400 bytes. This default value accommodates for the overhead
       of the GRE tunnel used to transport IPv4 packets between the BS and
       AR and the IP-transport header. The choice of default MTU value in
        IPv4-CS link is determined by the present deployment of IEEE 802.16
        network specifications and the legacy IPv4 client implementations
        where they do not typically ask for MTU configuration of the link,
        while DHCP servers are required to provide the MTU information only
        when requested. The default MTU value ensures that no packet loss
        happens at the L2 level due to the low-capacity IP CS link-MTU in
        order to accommodate the GRE encapsulation over IP-transport between
        the AR and BS.
 1400 bytes to accommodate GRE/IPSec/VLAN overhead
   – Avoids L2 packet loss and unnecessary fragmentation
                  Setting MTU dynamically
 The IEEE is currently revising 802.16 (802.16rev2)
 - To inform the SDU MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase, such that future
   IEEE 802.16 compliant clients can configure the negotiated MTU size for IP-CS link.
    – If MS and BS are connected with bridges then the SDU MTU may not
      provide correct information of the path

 All Future IPv4 and IP4-CS clients SHOULD implement
  DHCP interface MTU option [RFC 2132] at layer 3
    – Is SHOULD ok for this requirement?


 PMTU [RFC 1191] and PPMTUD[RFC 4821] are
  recommended for the new IPv4 and IP-CS client
  implementations
                     Other Changes

 Section 5.1 discusses router discovery mechanism and clarifies
  and IPv4 subnet model and address assignment
 Text added for handling multicast and broadcast address
  mapping – it clarifies that defining multicast/broadcast
  handling in 802.16 networks is out of scope. Some thoughts
  are presented at the Appendix section
 Clarified IPv4 CS sub-layer support (section 3.1)
 Clarified IPv4 CS link and link establishment (section 4, 4.1)
 Made reference to RFC 5154 and RFC 5121 for IPv4 network
  architecture over IEEE 802.16 networks (section 3)
                   Next revision

 Will fix typos and make minor editorial modifications
  before submission for AD review
 Adding a co-author : Gabriel Montenegro
                Acknowledgement

 Authors like to acknowledge Basavaraj Patil and DJ
  Johnston for educating us about the IEEE
  802.16Rev2 modifications for SDU MTU
   – Johnston, D., "SDU MTU Capability Declaration", March
     2008, <http://www.ieee.org/16>.
     Thanks!



samitac@ipinfusion.com

				
DOCUMENT INFO