One document matched: draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02.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-02.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>125 South Market Street, 9th Floor</street>
<city>San Jose, CA</city>
<country>USA</country>
</postal>
<email>samitac2@gmail.com</email>
</address>
</author>
<date month="February" 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
(Asynchronous Transfer Mode Convergence Sublayer (ATM CS) and Packet Convergence
Sublayer (Packet CS) are the two main service specific convergence sublayers)
for transmitting upper layer protocols. The packet CS 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 IP Convergence
Sublayer of the IEEE 802.16.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
IEEE 802.16 <xref target="_XREF_10" 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. IPv4 packets
can be carried over the IEEE 802.16 specified air interface via:
<t> </t>
<list style="numbers">
<t>
IP-specific part of the Packet CS or
</t>
<t>
IEEE 802.3-specific part of the Packet CS
</t>
</list>
</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>
The mobile station (MS)/host is attached to an access router via a
base station (BS). The MS and the BS are connected via the IEEE
802.16 air interface at the link and physical layers. The IPv4
link from the MS terminates at an access router that may be a part of
the BS or an entity beyond the BS. The base station is a layer 2
entity (from the perspective of the IPv4 link between the MS and
access router (AR)) and relays the IPv4 packets between the AR and
the MS via a point-to-point connection over the air interface.
</t>
<t>
This document specifies a method for encapsulating and transmitting
IPv4 <xref target='RFC0791'/> packets over 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 mentions about 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="_XREF_12" pageno="false" format="default"/>.
</t>
</section>
<section title="Typical Network Architecture for IPv4 over IEEE 802.16">
<t>
In a network that utilizes the IEEE 802.16 air interface, 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. The figure below illustrates the network architecture.
</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>
<section title="Frame Format for IPv4 Packets">
<t>
IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames as shown in
the following figure.
</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 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 6-byte
IEEE 802.16 MAC header over the air interface.
</t>
<t>
The Length parameter of IEEE 802.16 MAC frame has a size of 11 bits. Hence
the total PDU size is 2048 bytes. The IPv4 payload can be a maximum
value of 2038 bytes ( Total PDU size (2048) - (MAC Header (6) + CRC (4)), which
is the maximum possible MTU. The IPv4 payload size can vary and can be either
greater or less than the default value. The MTU value of the MS can be configured
via Path MTU Discovery <xref target='RFC1191'/>, Packetization layer path MTU
discovery <xref target='RFC4821'/>, DHCP MTU option <xref target='RFC2132'/>
or static configuration of each MS.
</t>
</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
point-to-point link between MS and AR, hence each MS shall be on different IP
subnet. The point-to-point link between MS and AR is achieved using a set of
IEEE 802.16 MAC connections (identified by CIDs) and at least an L2 tunnel (usually
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>
DHCP <xref target='RFC2131'/> SHOULD be used for assigning IPv4 address for
the MSs. DHCP messages are transported over IEEE 802.16 MAC transported connection
to and from the AR. In case DHCP server does not reside in AR, the AR SHOULD
implement DHCP relay Agent <xref target='RFC1542'/>.
</t>
</section>
<section title="Address Resolution Protocol">
<t>
The IP CS does not allow for transmission of ARP <xref target='RFC0826'/>
packets, accordingly, other mechanisms for address resolution must be used.
In a point-to-point link model, address resolution may not be 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.
</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="_XREF_10"
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="_XREF_11" 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, Gabriel Montenegro, Bachet Sarikaya, Basavaraj Patil,
Paolo Narvaez, and Bruno Sousa for their review and comments.
</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" ?>
</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" ?>
<reference anchor="_XREF_12" target="http://www.ietf.org/internet-drafts/
draft-ietf-16ng-ps-goals-04.txt">
<front><title>IP over 802.16 Problem Statement and Goals</title>
<author initials="J." surname="Jee"><organization/> </author>
<date month="December" year="2007" /></front>
</reference>
<reference anchor="_XREF_10">
<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="_XREF_11">
<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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:30:39 |