Is there really a demand to work on an update of the IPv4-CS I-D?
Which details would require/qualify for an IETF specification?
The current architectural model closely resembles the WiMAX
architecture, and WiMAX provides a comprehensive specification for it.
Bye
Max
On Thu, 12 Feb 2009, Riegel, Maximilian (NSN - DE/Munich) wrote:
Gabriel,
The WiMAX Forum NWG reviewed section 4-3 and Appendix C of
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt and would like to
make a couple of remarks on the MTU issue:
- The I-D is not very clear about the MTU issues appearing in an
IPv4
over IEEE 802.16 transmission system. The ambiguities mainly result
out of the vague definition of the IEEE 802.16 link comprising both
the radio part of the link as well as the part of the link between
BS
and AR, when the functions are located in different entities.
- Section 4.3 in particular misses the discussion of the
dependencies
between MTU size and the tunneling protocol deployed between BS and
AR.
- Section 4.3 also misses, that there is no packet loss when the MTU
size limitation is caused by the encapsulation overhead on the link
between BS and AR. E.g. when GRE is used for the tunnel between BS
and
AR, the transport IP layer can fragment the GRE packets to fit the
transport MTU on the link between BS and AR. Reassembly in the
tunnel
endpoint at the AR will re-establish the original user IP packet.
- Please note that the reason of the WiMAX NWG to limit the MTU
going
over IPv4-CS to 1400 Bytes was to avoid fragmentation on the link
between BS and ASN-GW as well as on the link between ASN-GW and CSN
(MIP tunnel). Fragmentation and re-assembly require considerable
processing power in the network elements.
- Appendix C makes statements which would require more detailed
review
of the I-D by WiMAX NWG. In particular 'The addressing and operation
of IPv4-CS described in this document are applicable to the WiMAX
networks as well' has not been verified yet.
Furthermore 'Thus, WiMAX MS nodes should use this default (1400) MTU
value per the current specification [WMF]. However, due to reasons
specified in section 4.3 above, it is strongly recommended that
future
WiMAX MS nodes support a default MTU of 1500 bytes, and that they
implement MTU negotiation capabilities as mentioned in this
document.'
makes recommendations to WiMAX without understanding the real
reasons
for the limitation of the MTU size in Mobile WiMAX.
We would recommend to 16ng to revise the sections on MTU size to
better explain the underlying issues leading to restrictions in the
MTU
size.
In particular the influence of tunneling inside the network should
be
carefully discussed.
In addition we would kindly ask to either remove whole Appendix C on
the WiMAX MTU size or revise the text explaining the real issues in
the WiMAX architecture. In particular the statements on the
applicability of the I-D on the WiMAX architecture and the
recommendation on future modifications in the WiMAX architecture
seem
not to be very appropriate to us.
Bye
Max
Vize Chair NWG
________________________________
From: ext Gabriel Montenegro
[mailto:Gabriel.Montenegro at microsoft.com]
Sent: Monday, November 03, 2008 11:59 AM
To: nwg-chair at list.wimaxforum.org
Cc: 'Daniel Soohong Park'
Subject: [nwg-chair] NWG feedback on 16ng's IPv4 CS draft
Prakash, Max and Yong Chang,
The IETF 16ng WG has published a revision of this draft:
"Transmission of IPv4 packets over IEEE 802.16's IP Convergence
Sublayer"
Per this announcement:
http://www.ietf.org/mail-archive/web/16ng/current/msg00863.html
<http://www.ietf.org/mail-archive/web/16ng/current/msg00863.html>
We understand that this specification currently is not normative to
NWG (as opposed to RFC5121 on IPv6 CS). Nevertheless, given its
relevance, and with the hope it may become normative to NWG in some
future revision, the 16ng WG would like to solicit feedback from NWG
on this draft.
In particular, please note that this draft specifies a default MTU
of
1500, which is different from the WiMAX-specified MTU of 1400 (per
the recently approved R1_V1.3.0-Stage-3 NWG specifications). For
MTU
discussion, please refer to these sections:
http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-0
4#
section-4.3
<http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-
04
#section-4.3>
http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-0
4#
appendix-C
<http://tools.ietf.org/html/draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-
04
#appendix-C>
The 16ng WG will next meet on Nov 18 during the IETF in Minneapolis
(https://datatracker.ietf.org/meeting/73/agenda.html). If at all
possible, it would be best if comments were received before that
date
in order for the WG to discuss them during the meeting.
Please send your comments to the 16ng at ietf.org
<mailto:16ng at ietf.org>
mailing list.
Thanks,
Gabriel and Daniel
16ng co-chairs
_______________________________________________
16NG mailing list
16NG at ietf.org
https://www.ietf.org/mailman/listinfo/16ng