Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 28, 2008.

Abstract

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.

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.

Table of Contents

1.  Introduction
2.  Terminology
3.  Typical Network Architecture for IPv4 over IEEE 802.16
4.  Frame Format for IPv4 Packets
5.  Maximum Transmission Unit
6.  Subnet Model and IPv4 Address Assignment
7.  Address Resolution Protocol
8.  IP Multicast Address Mapping
9.  Security Considerations
10.  IANA Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References
Appendix A.  Multiple Convergence Layers - Impact on Subnet Model
Appendix B.  Sending and Receiving IPv4 Packets
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

IEEE 802.16 [_XREF_10] (, “IEEE 802.16e, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed and Mobile broadband wireless access systems,” October 2005.) 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:

1. IP-specific part of the Packet CS or
2. IEEE 802.3-specific part of the Packet CS

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).

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.

This document specifies a method for encapsulating and transmitting IPv4 [RFC0791] (Postel, J., “Internet Protocol,” September 1981.) 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.

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.

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Terminology

The terminology in this document is based on the definitions in [_XREF_12] (Jee, J., “IP over 802.16 Problem Statement and Goals,” December 2007.).

3.  Typical Network Architecture for IPv4 over IEEE 802.16

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.

   +-----+   CID1    +------+          +-----------+
   | MS1 |----------+|  BS  |----------|     AR    |-----Internet
   +-----+         / +------+          +-----------+
      .           /        ____________
      .     CIDn /        ()__________()
   +-----+      /            L2 Tunnel
   | MSn |-----/
   +-----+

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.

4.  Frame Format for IPv4 Packets

IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames as shown in the following figure.

                     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) |
                    +-+-+-+-+-+-+-+-+

H: Header Type (1 bit). Shall be set to zero indicating that it is a Generic MAC PDU.

E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload is encrypted.

R: Reserved. Shall be set to zero.

C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included

EKS: Encryption Key Sequence

LEN: The Length in bytes of the MAC PDU including the MAC header and the CRC if present (11 bits)

CID: Connection Identifier (16 bits)

HCS: Header Check Sequence (8 bits)

CRC: An optional 8-bit field. CRC appended to the PDU after encryption.

TYPE: This field indicates the subheaders (Mesh subheader, Fragmentation Subheader, Packing subheader etc and special payload types (ARQ) present in the message payload

5.  Maximum Transmission Unit

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.

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 [RFC1191] (Mogul, J. and S. Deering, “Path MTU discovery,” November 1990.), Packetization layer path MTU discovery [RFC4821] (Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery,” March 2007.), DHCP MTU option [RFC2132] (Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.) or static configuration of each MS.

6.  Subnet Model and IPv4 Address Assignment

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.

DHCP [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) 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 [RFC1542] (Wimer, W., “Clarifications and Extensions for the Bootstrap Protocol,” October 1993.).

7.  Address Resolution Protocol

The IP CS does not allow for transmission of ARP [RFC0826] (Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” November 1982.) packets, accordingly, other mechanisms for address resolution must be used. In a point-to-point link model, address resolution may not be needed.

8.  IP Multicast Address Mapping

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.

9.  Security Considerations

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_10] (, “IEEE 802.16e, IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed and Mobile broadband wireless access systems,” October 2005.). 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_11] (, “WiMAX End-to-End Network Systems Architecture Stage 2-3 Release 1.2, http://www.wimaxforum.org/technology/documents,” January 2008.).

10.  IANA Considerations

This document has no actions for IANA.

11.  Acknowledgements

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.

12.  References

12.1. Normative References

12.2. Informative References

Appendix A.  Multiple Convergence Layers - Impact on Subnet Model

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 [RFC4840] (Aboba, B., Davies, E., and D. Thaler, “Multiple Encapsulation Methods Considered Harmful,” April 2007.).

Appendix B.  Sending and Receiving IPv4 Packets

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.

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.

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.

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.

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.

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.