Transcript IPv4 over IEEE 802.16 IP CS

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!
[email protected]