One document matched: draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1191 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC4821 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4821.xml">
]>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr="pre5378Trust200902" category="std" docName="draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07">
<front>
<title abbrev="IPv4 over IEEE 802.16's IPv4 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="June" year="2010"/>
<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) and IEEE 802.3 (Ethernet).
The IP-specific part of the Packet CS enables the transport
of IPv4 packets directly over the IEEE 802.16 Media Access Control (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 layers. The MAC includes various
Convergence Sublayers (CS) for transmitting higher layer packets including IPv4
packets <xref target="IEEE802_16" />.
</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")
for hosts served by a network that utilizes the IEEE Std 802.16 air interface.
</t>
<t>
This document specifies a method for encapsulating and transmitting
IPv4 <xref target='RFC0791'/> packets over the IPv4 CS of IEEE 802.16. This
document also specifies the MTU and address assignment method for hosts
using IPv4 CS.
</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>
<list style="symbols">
<t>
Mobile Station (MS) -
The term MS is used to mean an IP host. This usage is more informal than that in IEEE 802.16,
in which "MS" refers to the interface implementing the IEEE 802.16 MAC and
PHY layers and not to the entire host.
</t>
</list>
</t>
<t>
Other 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' />.
Namely, each MS is attached
to an Access Router (AR) through a Base Station (BS), a layer 2 entity
(from the perspective of the IPv4 link between the MS and
the AR).
</t>
<t>
For further information on the typical network architecture, see <xref target='RFC5121' />
section 5.
</t>
<section title ="IEEE 802.16 IPv4 Convergence Sublayer Support">
<t>
As described in <xref target="IEEE802_16"/>, the IP-specific part of the packet CS
allows the transmission of either IPv4 or IPv6 payloads.
In this document, we are focusing on the
IPv4 over Packet Convergence Sublayer.
</t>
<t>
For further information on the IEEE 802.16 Convergence Sublayer and encapsulation
of IP packets, see <xref target='RFC5121' /> section 4 and <xref target="IEEE802_16"/>.
</t>
</section>
</section>
<section title="IPv4 CS link in 802.16 Networks">
<t>
In 802.16, the transport connection between an MS and a BS is used to
transport user data, i.e., IPv4 packets in this case. A transport
connection is represented by a service flow, and multiple transport
connections can exist between an MS and a BS.
</t>
<t>
When an AR and a BS are colocated, the collection of transport
connections to an MS is defined as a single IPv4 link. When an AR and a
BS are separated, it is recommended that a tunnel be established
between the AR and a BS whose granularity is no greater than 'per MS'
or 'per service flow' (An MS can have multiple service flows which
are identified by a service flow ID). Then the tunnel(s) for an MS,
in combination with the MS's transport connections, forms a single
point-to-point IPv4 link.
</t>
<t>
Each host belongs to a different IPv4 link and is assigned an unique IPv4 address
per recommendations in <xref target='RFC4968'/>.
</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, a service flow is created that
can be used for exchanging IP layer signaling messages, e.g. address assignment
procedures 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>
Here, "MSB" means "most significant byte", and "LSB" means "least significant byte".
</t>
<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 = 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 (e.g., see the bottom of this section for some possible mechanisms).
The default MTU for IPv4 packets over an IEEE 802.16
link SHOULD be 1500 octets. Given the possibility for "in-the-network" tunneling,
supporting this MTU at the endhosts has implications on
the underlying network, for example, as discussed in <xref target='RFC4459' />.
</t>
<t>
Per <xref target='RFC5121' /> section 6.3, the IP MTU can vary
to be larger or smaller than 1500 octets.
</t>
<t>
If an MS transmits 1500-octet packets in a deployment with a smaller MTU,
packets from the MS may be dropped at the link-layer silently.
Unlike IPv6, in which departures
from the default MTU are readily advertised via the MTU option in
Neighbor Discovery (via router advertisement), there is no similarly reliable mechanism in IPv4,
as the legacy IPv4 client implementations do not determine the link MTU by
default before sending packets. Even though there is a DHCP option
to accomplish this, DHCP servers are required
to provide the MTU information only when requested.
</t>
<t>
5. Subnet Model and IPv4 Address Assignment
The Subnet Model recommended for IPv4 over IEEE 802.16 using IPv4 CS
is based on the point-to-point link between MS and AR [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
service flows) and an L2 tunnel (e.g., 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.
The 'Next hop' IP address of the IPv4 CS MS is always the IP address
of the AR, because MS and AR are attached via a point-to-point link.
5.1. IPv4 Unicast Address Assignment
DHCP [RFC2131] SHOULD be used for assigning IPv4 address for the MS.
DHCP messages are transported over the IEEE 802.16 MAC connection to
and from the BS and relayed to the AR. In case the DHCP server does
not reside in the AR, the AR SHOULD implement a DHCP relay Agent
[RFC1542].
5.2. Address Resolution Protocol
The IPv4 CS does not allow for transmission of ARP [RFC0826] packets.
Furthermore, in a point-to-point link model, address resolution is
not needed.
5.3. IP Broadcast and Multicast
Multicast or broadcast packets from the MS are delivered to the AR
via the BS through the point-to-point link. This specification
simply assumes that the broadcast and multicast services are
provided. How these services are implemented in an IEEE 802.16
Packet CS deployment is out of scope of this document.
Discovery
and configuration of the proper link MTU value ensures adequate usage of
the network bandwidth and resources.
Accordingly, deployments should avoid packet loss
due to a mismatch between the default MTU
and the configured link MTUs.
</t>
<t>
Some of the mechanisms available for the IPv4 CS host to find out the
link's MTU value and mitigate MTU-related issues are:
</t>
<t>
<list style="symbols">
<t>
The IEEE recently revised 802.16 (see IEEE 802.16-2009 <xref target="IEEE802_16"/>) to
(among other things) allow providing the Service
Data Unit or MAC MTU in the IEEE 802.16 SBC-REQ/SBC-RSP phase, such that
IEEE 802.16 compliant clients can infer and configure the negotiated MTU size for the
IPv4 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 the DHCP
interface MTU option <xref target='RFC2132'/>.
</t>
</list>
</t>
<t>
This document recommends that implementations of IPv4 and
IPv4 CS clients SHOULD implement the DHCP interface MTU option [RFC2132] in
order to configure its interface MTU accordingly.
</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 IEEE 802.16-2009<xref target="IEEE802_16" />.
</t>
<t>
Additionally, the clients are encouraged to run
PMTU <xref target="RFC1191" /> or PPMTUD <xref target="RFC4821" />.
However, the 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 the 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 access networks.
</t>
</section>
</section>
<section title="Subnet Model and IPv4 Address Assignment">
<t>
The Subnet Model recommended for IPv4 over IEEE 802.16 using IPv4 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 service flows) and an L2 tunnel (e.g., 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>
<t>
The 'Next hop' IP address of the IPv4 CS MS is always the IP address of the AR, because MS and
AR are attached via a point-to-point link.
</t>
<section title="IPv4 Unicast Address Assignment">
<t>
DHCP <xref target='RFC2131'/> SHOULD be used for assigning IPv4 address for
the MS. DHCP messages are transported over the IEEE 802.16 MAC connection
to and from the BS and relayed to the AR. In case the DHCP server
does not reside in the AR, the AR SHOULD
implement a DHCP relay Agent <xref target='RFC1542'/>.
</t>
</section>
<section title="Address Resolution Protocol">
<t>
The IPv4 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 Broadcast and Multicast">
<t>
Multicast or broadcast packets from the MS are delivered to the AR
via the BS
through the point-to-point link.
This specification simply assumes that the broadcast and multicast
services are provided. How these services are implemented in an IEEE 802.16
Packet CS deployment is out of scope of this document.
</t>
</section>
</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'>
<reference anchor="IEEE802_16">
<front>
<title abbrev="IEEE802.16">IEEE Std 802.16-2009, Draft Standard for Local and
Metropolitan area networks, Part 16: Air Interface for
Broadband Wireless Access Systems</title>,
http://standards.ieee.org/getieee802/download/802.16-2009.pdf,
<date year="2009" month="May" />
</front>
</reference>
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0826" ?>
<?rfc include="reference.RFC.1542" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2131" ?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.1191" ?>
<?rfc include="reference.RFC.2132" ?>
<?rfc include="reference.RFC.4459" ?>
<?rfc include="reference.RFC.4821" ?>
<?rfc include="reference.RFC.4840" ?>
<?rfc include="reference.RFC.4968" ?>
<?rfc include="reference.RFC.5121" ?>
<?rfc include="reference.RFC.5154" ?>
<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/</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 IPv4 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 to
<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 are transmitted, a 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 (if these
two are not co-located). This
IEEE 802.16 transport connection provides a point-to-point link between
the MS and AR. All the packets originated at the MS always reach the 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 place 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 optionally reconstructs the payload header if PHS is in use.
It then tunnels the packet that has been received on a particular MAC connection
to the AR. Similarly the packets received on a tunnel
interface from the AR, would be mapped to a particular CID using the IPv4 classification
mechanism.
</t>
<t>
AR performs normal routing for the packets that it receives, processing them per
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. The particular method is out of scope of this specification
as it need not depend on any particularities of IEEE 802.16.
</t>
</appendix>
<appendix title="WiMAX IPCS MTU size">
<t>
WiMAX (Worldwide Interoperability for Microwave Access) forum has defined a
network architecture <xref target="WMF"/>. Furthermore, WiMAX has specified
IPv4 CS support for transmission of
IPv4 packets between MS and BS over the IEEE 802.16 link. The WiMAX IPv4 CS
and this specification are similar.
One significant difference, however, is that the WiMAX
Forum <xref target="WMF"/> has specified the IP MTU as 1400 octets
<xref target="WMF"/> as opposed to 1500 in this specification.
</t>
<t>
Hence if an IPv4 CS MS configured with an MTU of 1500 octet enters
a WiMAX network, some of the issues mentioned in this specification
may arise.
As mentioned in section 4.3, the possible mechanisms are not guaranteed
to work. Furthermore,
an IPv4 CS client is not capable of doing ARP probing
to find out the link MTU.
On the other hand, it is imperative for an MS to know the link
MTU size. In practice, an MS should
be able to sense or deduce the fact that it is operating within a WiMAX
network (e.g., given the WiMAX-specific particularities of the authentication and
network entry procedures), and adjust its MTU size
accordingly.
Even though this method is not perfect, and the potential
for conflict may remain, this document recommends a default MTU of 1500. This represents
the WG's consensus (after much debate) to select the best value for IEEE802.16
from the point of view of the IETF, in spite of WiMAX Forum's deployment.
</t>
</appendix>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:30:28 |