One document matched: draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr="full3978" category="std" docName="draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04.txt">
<front>
<title abbrev="IPv4 over IEEE 802.16's IP CS"> Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer</title>
<author initials="S" surname="Madanapalli"
fullname="Syam Madanapalli">
<organization>Ordyn Technologies</organization>
<address>
<postal>
<street>1st Floor, Creator Building, ITPL</street>
<city>Bangalore - 560066</city>
<country>India</country>
</postal>
<email>smadanapalli@gmail.com</email>
</address>
</author>
<author initials="Soohong D" surname="Park"
fullname="Soohong Daniel Park">
<organization>Samsung Electronics</organization>
<address>
<postal>
<street>416 Maetan-3dong, Yeongtong-gu</street>
<city>Suwon 442-742</city>
<country>Korea</country>
</postal>
<email>soohong.park@samsung.com</email>
</address>
</author>
<author initials="S" surname="Chakrabarti"
fullname="Samita Chakrabarti">
<organization>IP Infusion</organization>
<address>
<postal>
<street>1188 Arques Avenue</street>
<city>Sunnyvale, CA</city>
<country>USA</country>
</postal>
<email>samitac@ipinfusion.com</email>
</address>
</author>
<author initials="G" surname="Montenegro"
fullname="Gabriel Montenegro">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street></street>
<city>Redmond, Washington</city>
<country>USA</country>
</postal>
<email>gabriel.montenegro@microsoft.com</email>
</address>
</author>
<date month="October" year="2008"/>
<area>Internet</area>
<workgroup>16ng Working Group</workgroup>
<abstract>
<t>
IEEE 802.16 is an air interface specification for wireless broadband access.
IEEE 802.16 has specified multiple service specific convergence sublayers
for transmitting upper layer protocols. The packet CS (Packet Convergence Sublayer)
is used for the transport
of all packet-based protocols such as Internet Protocol (IP), IEEE 802.3 (Ethernet)
and IEEE 802.1Q (VLAN). The IP-specific part of the Packet CS enables the transport
of IPv4 packets directly over the IEEE 802.16 MAC.
</t>
<t>
This document specifies the frame format, the Maximum Transmission Unit (MTU)
and address assignment procedures for transmitting IPv4 packets over the IP-specific
part of the Packet Convergence Sublayer of IEEE 802.16.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
IEEE 802.16 <xref target="IEEE802_16" pageno="false" format="default"/> is a
connection oriented access technology for the last mile. The IEEE 802.16
specification includes the PHY and MAC details. The MAC includes various
convergence sublayers (CS) for transmitting higher layer packets including IPV4
packets <xref target='RFC5154' />.
</t>
<t>
The scope of this specification is limited to the operation of IPv4
over the IP-specific part of the packet CS (referred to as "IPv4 CS" or
simply "IP CS" in this document).
</t>
<t>
This document specifies a method for encapsulating and transmitting
IPv4 <xref target='RFC0791'/> packets over the IP CS of IEEE 802.16. This
document also specifies the MTU and address assignment method for the
IEEE 802.16 based networks using IP CS.
</t>
<t>
This document also discusses ARP (Address Resolution Protocol)
and Multicast Address Mapping whose operation is similar to any other
point-to-point link model.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target='RFC2119'/>.
</t>
</section>
<section title="Terminology">
<t>
The terminology in this document is based on the definitions in
<xref target='RFC5154' />.
</t>
</section>
<section title="Typical Network Architecture for IPv4 over IEEE 802.16">
<t>
The network architecture follows what is described in <xref target='RFC5154' /> and
<xref target='RFC5121' />.
In a nutshell, each MS is attached
to an Access Router (AR) through a Base Station (BS), a layer 2 entity.
The AR can be an integral part of the BS or the AR could be an entity
beyond the BS within the access network. IPv4 packets between the MS
and BS are carried over a point-to-point MAC transport connection which
has a unique connection identifier (CID). The packets between BS and AR
are carried using L2 tunnel (typically GRE tunnel) so that MS and AR are
seen as layer 3 peer entities. At least one L2 tunnel is required for
each MS, so that IP packets can be sent to MSs before they acquire IP
addresses. From the layer 3 perspective, MS and AR are connected by a point-to-point
link. The figure below illustrates the network architecture for convenience.
</t>
<figure anchor="Network Architecture" title="Typical Network
Architecture for IPv4 over IEEE 802.16">
<artwork><![CDATA[
+-----+ CID1 +------+ +-----------+
| MS1 |----------+| BS |----------| AR |-----Internet
+-----+ / +------+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+
]]></artwork> </figure>
<t> </t>
<t>
The above network model serves as an example and is shown to illustrate
the point to point link between the MS and the AR. The L2 tunnel is not
required if BS and AR are integrated into a single box.
</t>
<section title ="IEEE 802.16 IPv4 Convergence sub-layer support">
<t>
As described in <xref target='RFC5154'/> section 3.3., an IP specific subpart classifier
carries either IPv4 or IPv6 payloads. In this document, we are focussing on
IPv4 over IP Convergence sublayer.
</t>
<t>
The convergence sublayer maintains an ordered "classifier table". Each
entry in the classifier table includes a classifier and a target CID.
In case of IP convergence sub-layer, the base-station performs the mapping
between CID or service-flow ID and a corresponding GRE key for a particular
IP-CS session. Also the classification takes place in Access Router based on
the GRE key per service-flow and/or IP-address of the MS.
</t>
<t>
The other classifiers in Packet CS are IPv6 CS and Ethernet CS <xref target='RFC5154'/>.
The classifiers used by IP CS, enable the differentiation of IPv4 and IPv6 packets
and their mapping to specific transport connections over the air interface.
</t>
<t>
The figure below shows the IPv4 user payload over IP transport over the packet
CS of IEEE 802.16:
<figure anchor="IPCS Format" title="IEEE 802.16 transport of
IPv4 Packets from MS to AR">
<artwork><![CDATA[
+-------------------+
| IPv4 Payload |
+-------------------+
| GRE |
+-------------------+ +-------------------+
| IPv4 Payload | | IP |
+-------------------+ +-------------------+
| IP-specific | | BS-AR Layer 2 |
| part of Packet CS | | specific link |
|...................| | (Ex: Ethernet) |
| 802.16 MAC | | |
+-------------------+ +-------------------+
| PHY | | PHY |
+-------------------+ +-------------------+
(1) IPv4 over IP-CS (2) IPv4 in L3 GRE encapsulation
between MS and BS between Base-station and AR
]]></artwork> </figure>
</t>
</section>
</section>
<section title="IPv4-CS link in 802.16 Networks">
<t>
In this document we have defined IPv4 CS link as a point-to-point link between
the MS and the AR using a set of service flows consisting of MAC transport
connections between a MS and BS, and L2 tunnel(s) between between a BS and AR.
It is recommended that a tunnel be established
between the AR and a BS based on 'per MS'
or 'per service flow' (An MS can have multiple service flows each of which
are identified by a unique service flow ID). Then the tunnel(s) for an MS,
in combination with the MS's MAC transport connections, forms a single
point-to-point link.
Each MS belongs to a different link and is assigned an unique IPv4 address
per recommendations
in <xref target='RFC4968'/>.
In summary:
</t>
<t>
<list style="symbols">
<t>
IPv4-CS uses the IPv4 header fields to classify the packets and map to appropriate CID.
</t>
<t>
Point-to-point link between MS and AR is established.
</t>
</list>
</t>
<section title="IPv4-CS link establishment">
<t>
In order to enable the sending and receiving of IPv4 packets between
the MS and the AR, the link between the MS and the AR via the BS
needs to be established. This section explains the link
establishment procedures following section 6.2 of <xref target='RFC5121' />.
Steps 1-4 are same as indicated in 6.2 of <xref target='RFC5121' />. In step 5,
support for IPv4 is indicated. In step 6, an initial service flow is created that
can be used for exchanging IP layer signaling messages, e.g. address assignment
procedures using DHCP. </t>
<t>
The address assignment procedure depends on
the MS mode - i,e. whether it is acting as a Mobile IPv4 client or a Proxy Mobile
IP client or a Simple IP client. In the most common case, the MS requests an IP address
using DHCP.
</t>
</section>
<section title="Frame Format for IPv4 Packets">
<t>
IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames in the data payloads of the
802.16 PDU ( see section 3.2 of <xref target='RFC5154'/> ).
</t>
<figure anchor="Frame Format" title="IEEE 802.16 MAC Frame Format for
IPv4 Packets">
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|E| TYPE |R|C|EKS|R|LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LEN LSB | CID MSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID LSB | HCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 |
+- -+
| header |
+- -+
| and |
+- -+
/ payload /
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CRC (optional) |
+-+-+-+-+-+-+-+-+
]]></artwork> </figure>
<list style="empty">
<t>
H: Header Type (1 bit). Shall be set to zero indicating that it
is a Generic MAC PDU.
</t>
<t>
E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload
is encrypted.
</t>
<t>
R: Reserved. Shall be set to zero.
</t>
<t>
C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included
</t>
<t>
EKS: Encryption Key Sequence
</t>
<t>
LEN: The Length in bytes of the MAC PDU including the MAC header
and the CRC if present (11 bits)
</t>
<t>
CID: Connection Identifier (16 bits)
</t>
<t>
HCS: Header Check Sequence (8 bits)
</t>
<t>
CRC: An optional 8-bit field. CRC appended to the PDU after
encryption.
</t>
<t>
TYPE: This field indicates the subheaders (Mesh subheader,
Fragmentation Subheader, Packing subheader etc and special payload
types (ARQ) present in the message payload
</t>
</list>
</section>
<section title="Maximum Transmission Unit">
<t>
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 SHOULD be 1500 bytes.
In some deployments, BS and AR are separate entities; an encapsulation may be used
to transport IPv4 packets between the BS and AR. In those cases the overhead
of encapsulation may be considered in the link MTU configuration.
</t>
<t>
Note, if a deployment configures the 802.16 link MTU less than 1500,
then 1500 byte packets from the MS will be dropped at the link-layer silently;
the legacy IPv4 client implementations do not determine the link MTU by
default before sending packets, while the DHCP servers are required
to provide the MTU information only when requested. Please see
Appendix C. for the default MTU value in WiMAX <xref target="WMF"/> deployed networks.
</t>
<t>
This document recommends that a deployment should ensure that no packet loss
happens at the L2 level over IPV4 CS link-MTU, due to mismatch in default MTU
and the configured link MTUs.
</t>
<t>
However, it is strongly recommended that an IPv4 CS client host configure
the link-MTU before initiating the IP-level packet exchange.
The following paragraph discusses different approaches through which
the IPv4 CS client finds out the available link-MTU value. The discovery
and configuration of a proper link MTU value ensures adequate usage of
the network bandwidth and resource.
</t>
<t>
<list style="symbols">
<t>
The IEEE is currently revising 802.16 (see 802.16Rev2 <xref target="802_16REV2"/> ) to
reproduce capabilities to inform the Service
Data Unit or MAC 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.
However, the implementation must communicate the negotiated MTU value to the IP layer
to adjust the IP Maximum payload size for proper handling of fragmentation. Note that
this method is useful only when MS is directly connected to the BS.
</t>
<t>
Configuration and negotiation of MTU size at the network-layer by using DHCP
interface MTU option <xref target='RFC2132'/>.
</t>
</list>
</t>
<t>
This document recommends that all future implementations of IPv4 and
IPv4-CS clients SHOULD implement DHCP interface MTU option [RFC2132] in
order to configure its interface MTU according to the access network in
order to maximize the capacity of the bandwidth of
the network. Thus the IPv4 stack should have capability to adjust
the MTU value based on the DHCP response.
</t>
<t>
In the absence of DHCP MTU configuration, the client node (MS) has two
alternatives: 1) use the default MTU (1500 bytes) or 2) determine
the MTU by the methods described in <xref target="802_16REV2" />.
</t>
<t>
Additionally, the clients are encouraged to run
PMTU[RFC 1191] or PPMTUD[RFC 4821].
However, PMTU mechanism has inherent problems of packet
loss due to ICMP messages not reaching the
sender and IPv4 routers not fragmenting the packets due to DF bit being
set in the IP packet. The above mentioned path MTU mechanisms will take
care of the MTU size between the MS and its correspondent node across
different flavors of convergence layers in the WiMAX networks and other types of IP networks.
</t>
</section>
</section>
<section title="Subnet Model and IPv4 Address Assignment">
<t>
The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is based on the
point-to-point link between MS and AR <xref target='RFC4968'/>, hence each MS shall be assigned an address with
32bit prefix-length or subnet-mask. The point-to-point link between MS and AR is achieved using a set of
IEEE 802.16 MAC connections (identified by CIDs) and a L2 tunnel (usually a
GRE tunnel) per MS between BS and AR. If the AR is co-located with the BS then the
set of IEEE 802.16 MAC connections between the MS and BS/AR represent the point-to-
point connection.
</t>
<section title="IPv4 Unicast Address Assignment and Router Discovery">
<t>
DHCP <xref target='RFC2131'/> SHOULD be used for assigning IPv4 address for
the MS. DHCP messages are transported over IEEE 802.16 MAC connection
to and from the BS and relayed to the AR. In case DHCP server does not reside in the AR, the AR SHOULD
implement DHCP relay Agent <xref target='RFC1542'/>. Please refer to the MTU section of this
document for requirements of DHCP interface-MTU option for the new IPv4 CS MS implementation.
</t>
<t>
Although DHCP is the recommended method of address assignment, it is possible that the
MS could be a pure Mobile-IPv4 <xref target='RFC3344'/> device or Wimax Mobile-IPv4 client which will
be offered an IP-address from its home-network after success-ful Mobile-IP <xref target='RFC3344'/>
registration. In such situation, the mobile-client implementation SHOULD use the default
link MTU in order to avoid any link-layer packet loss due to larger than supported packet
size in the IP CS link.
</t>
<t>
Router discovery messages <xref target='RFC1256'/> contain router solicitation and
router advertisements. The Router
solicitation messages (multicast or broadcast) are directly delivered to AR via BS from
the MS through the point-to-point link. The BS SHOULD map the all-router multicast nodes
or broadcast nodes for router discovery to the AR's IP-address and delivered directly to
the AR. Similarly for router-advertisement to the all-node multicast nodes will be either unicasted
to each MS by the BS separately or put onto a multicast connection to which all MSs are
listening to. If no multicast connection exists, and the BS does not have the capability to
aggregate and de-aggregate the messages from and to the MS hosts, then the AR implementation must take care
of sending unicast messages to the corresponding individual MS hosts within the set
of broadcast or multicast recipients. However, this specification simply assumes that the multicast
service is provided. How the multicast service is implemented in IEEE 802.16 Packet CS network, is
out of scope of this document.
</t>
<t>
The 'Next-hop' IP-address of the IP CS MS is always the IP-address of the AR, because MS and
AR are attached with a point-to-point link.
</t>
</section>
<section title="Address Resolution Protocol">
<t>
The IP CS does not allow for transmission of ARP <xref target='RFC0826'/>
packets. Furthermore,
in a point-to-point link model, address resolution is not needed.
</t>
</section>
<section title="IP Multicast Address Mapping">
<t>
IPv4 multicast packets are carried over the point-to-point link between the
AR and the MS (via the BS). The IPv4 multicast packets are classified normally
at the IP CS if the IEEE 802.16 MAC connection has been setup with a multicast
IP address as a classification parameter for the destination IP address.
The IPv4 multicast address may be mapped into multicast CID defined in IEEE 802.16
specification, but the mapping mechanism at the BS or efficiency of using multicast CID as
opposed to simulating multicast by generating multiple unicast messages are out of
scope of this document. However, it has been studied that the use of multicast CID for
realizing multicast transmissions reduces transmission efficiency when the multicast group
is small, due to the nature of wireless network(IEEE 802.16) <xref target="ETHCS"/>.
</t>
</section>
</section>
<section title="Handling Multicast and Broadcast packets in IPv4 CS">
<t>
In the IP-CS link model, two
different approaches can work - 1) BS maps the multicast or Broadcast IP-addresses
into different multicast CIDs of the MSs or 2) AR maps the multicast IP-addresses to different
unicast IP-addresses and send the packets directly to each MS separately.
</t>
<t>
However as mentioned earlier, handling a mechanism of multicast
or broadcast IP CS packets are out of scope of this document. Please refer to Appendix section for
some thoughts and suggestions.
</t>
</section>
<section title="Security Considerations">
<t>
This document specifies transmission of IPv4 packets over IEEE 802.16
networks with IPv4 Convergence Sublayer and does not introduce any
new vulnerabilities to IPv4 specifications or operation. The security
of the IEEE 802.16 air interface is the subject of <xref target="IEEE802_16"
pageno="false" format="default"/>. In addition, the security issues
of the network architecture spanning beyond the IEEE 802.16 base stations
is the subject of the documents defining such architectures, such as
WiMAX Network Architecture <xref target="WMF" pageno="false"
format="default"/>.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Acknowledgements">
<t>
The authors would like to acknowledge the contributions of Bernard Aboba,
Dave Thaler, Jari Arkko, Bachet Sarikaya, Basavaraj Patil,
Paolo Narvaez, and Bruno Sousa for their review and comments.
The working group members Burcak Beser, Wesley George, Max Riegel and DJ Johnston helped
shape the MTU discussion for IPv4 CS link. Thanks to many other members of the 16ng working
group who commented on this document to make it better.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0826" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.1542" ?>
<?rfc include="reference.RFC.5121" ?>
<?rfc include="reference.RFC.5154" ?>
<?rfc include="reference.RFC.4968" ?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.1191" ?>
<?rfc include="reference.RFC.4821" ?>
<?rfc include="reference.RFC.2132" ?>
<?rfc include="reference.RFC.4840" ?>
<?rfc include="reference.RFC.3344" ?>
<?rfc include="reference.RFC.1256" ?>
<reference anchor="ETHCS" target="http://www.ietf.org/internet-drafts/
draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt">
<front><title>Transmission of IP over Ethernet over IEEE 802.16 Networks</title>
<author initials="H." surname="Jeon"><organization/> </author>
<author initials="M." surname="Riegel"><organization/> </author>
<author initials="S." surname="Jeong"><organization/> </author>
<date month="April" year="2008" /></front>
</reference>
<reference anchor="802_16REV2" target="http://www.ieee.org/16">
<front><title>SDU MTU Capability Declaration</title>
<author initials="D." surname="Johnston"><organization/> </author>
<date month="March" year="2008" /></front>
</reference>
<reference anchor="IEEE802_16">
<front>
<title abbrev="IEEE802.16e">IEEE 802.16e, IEEE standard for Local and
metropolitan area networks, Part 16:Air Interface for fixed and Mobile
broadband wireless access systems</title>
<date year="2005" month="October" />
</front>
</reference>
<reference anchor="WMF">
<front>
<title abbrev="WiMAX Arch">WiMAX End-to-End Network Systems Architecture
Stage 2-3 Release 1.2, http://www.wimaxforum.org/technology/documents</title>
<date year="2008" month="January"/>
</front>
</reference>
</references>
<appendix title="Multiple Convergence Layers - Impact on Subnet Model">
<t>
Two different MSs using two different convergence sublayers (e.g. an MS using
Ethernet CS only and another MS using IP CS only) cannot communicate at data link
layer and requires interworking at IP layer. For this reason, these two nodes
must be configured to be on two different subnets. For more information refer
<xref target='RFC4840'/>.
</t>
</appendix>
<appendix title="Sending and Receiving IPv4 Packets">
<t>
IEEE 802.16 MAC is a point-to-multipoint connection oriented air-interface,
and the process of sending and receiving of IPv4 packets is different
from multicast capable shared medium technologies like Ethernet.
</t>
<t>
Before any packets being transmitted, IEEE 802.16 transport connection
must be established. This connection consists of IEEE 802.16 MAC transport
connection between MS and BS and an L2 tunnel between BS and AR. This
IEEE 802.16 transport connection provides a point-to-point link between
MS and AR. All the packets originated at the MS always reach AR before
being transmitted to the final destination.
</t>
<t>
IPv4 packets are carried directly in the payload of IEEE 802.16 frames when
the IPv4 CS is used. IPv4 CS classifies the packet based on upper layer
(IP and transport layers)header fields to put the packet on one of the
available connections identified by the CID. The classifiers for the IPv4
CS are source and destination IPv4 addresses, source and destinations
ports, Type-of-Service and IP protocol field. The CS may employ Packet
Header Suppression (PHS) after the classification.
</t>
<t>
The BS tunnels the packet that has been received on a particular MAC connection
to the AR. BS reconstructs the payload header if the PHS is in use before
the packet is tunneled to the AR. Similarly the packets received on a tunnel
interface from the AR, would be mapped to a particular CID using IPv4 classification
mechanism.
</t>
<t>
AR performs normal routing for the packets that it receives and forwards the packet
based on its forwarding table. However the DHCP relay agent in the AR, MUST maintain
the tunnel interface on which it receives DHCP requests, so that it can relay the
DHCP responses to the correct MS. One way of doing this is to have a mapping between
MAC address and Tunnel Identifier.
</t>
</appendix>
<appendix title="Wimax IPCS MTU size">
<t>
WiMAX (Worldwide Interoperability for Microwave Access) forum has defined a
network architecture<xref target="WMF"/> where IPV4 CS is supported for transmission of
IPV4 packets between MS and BS over the IEEE 802.16 link.
The addressing and operation of IPV4CS described in this
document are applicable to the WiMAX networks as well. The WiMAX
forum <xref target="WMF"/> has specified the Max SDU size as 1522 octets. However,
it specifies that IP-payload in WiMAX architecture<xref target="WMF"/> is 1400 bytes.
</t>
<t>
Hence if a IPV4-CS MS is configured with 1500 bytes it will have to be
communicated by the access router(AR) about the default link MTU
(1400 bytes) in WiMAX network. However, currently in IPv4 client
architecture a node is not required to ask for MTU option in its DHCP
messages nor an IPv4 router-advertisement can inform the node about
the link MTU. An IPV4CS client is not capable of doing ARP probing either
to find out the link MTU. Thus current specifications of WiMAX
network access routers cannot communicate its link MTU to the IPV4CS
MS. On the other hand, it is imperative for an MS to know the link
MTU size if it is not the default MTU value for de-facto standard in
order to successfully send packets in the network towards the first
hop. Some implementations with IEEE 802.16 layer 2 support, should
be able to sense IPV4CS WiMAX network and adjust their MTU size
accordingly, however this document does not make any assumptions on
this requirement.
</t>
<t>
Thus, WiMAX MS nodes should use this default (1400) MTU value
per the current specification <xref target="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.
</t>
</appendix>
<appendix title="Thoughts on handling multicast-broadcast IP packets">
<t>
Although this document does not directly specify details of multicast or broadcast
packet handling, here are some suggestions:
</t>
<t>
While uplink connections from the MSs to the BS provide only unicast
transmission capabilities, downlink connections can be used for
multicast transmission to a group of MSs as well as unicast
transmission from the BS to a single MS.
For all-node IP-addresses, the AR or BS should have special mapping and the packets should be
distributed to all active point-to-point connections by the AR or by the BS.
All-router multicast packets and any broadcast packets from a MS will be forwarded to
the AR by the BS.
If BS and MS are co-located, then the first approach is more useful. If the AR and BS
are located separately then the second approach SHOULD be implemented. An initial capability
exchange message should be performed between BS and AR (if they are not co-located)
to determine who would perform the distribution of multicast/broadcast packets. Such
mechansim should be part of L2 exchange during the connection setup and is out of scope
of this document.
In order to save energy of the wireless end-devices in the IEEE 802.16 wireless network,
it is recommened that the multicast and broadcast from network side to device side
should be reduced. Only DHCP, IGMP, Router-advertisemnet packets are allowed on the
downlink for multicast and broadcast IP-addresses. Other protocols using multicast and broadcast
IP-addresses should be permitted through local AR/BS configuration.
</t>
</appendix>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:29:21 |