16ng Working Group S. Madanapalli
Internet-Draft LogicaCMG
Intended status: Standards Track Soohong D. Park
Expires: August 11, 2007 Samsung Electronics
February 7, 2007
Transmission of IPv4 packets over 802.16's IP Convergence Sublayer
draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.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 11, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
IEEE 802.16 is an air interface specification for wireless broadband
access. IEEE has specified several service specific convergence
sublayers (CS) for 802.16 which are used by upper layer protocols.
The ATM CS and Packet CS are the two main service-specific
convergence sublayers and these are a part of the 802.16 MAC which
the upper layers interface to. The packet CS is used for transport
for all packet-based protocols such as Internet Protocol (IP), IEEE
Madanapalli & Park Expires August 11, 2007 [Page 1]
Internet-Draft IPv4 over 802.16's IP CS February 2007
Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific
part of the Packet CS enables transport of IPv4 packets directly over
the 802.16 MAC.
This document specifies the frame format, the Maximum Transmission
Unit (MTU) and address assignment procedures for transmitting Pv4
packets over IP Convergence Sublayer (IPCS) of IEEE 802.16. This
document describes on how to deal with Address Resolution Protocol
(ARP) and Mapping of multicast IP address to MAC address.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Typical Network Architecture for IPv4 over 802.16 . . . . . . 3
4. Frame Format for IPv4 Packets . . . . . . . . . . . . . . . . 4
5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
6. IPv4 Address Assignment . . . . . . . . . . . . . . . . . . . 6
7. Address Resolution Protocol . . . . . . . . . . . . . . . . . 6
8. IP Multicast Address Mapping . . . . . . . . . . . . . . . . . 6
9. Sending and Receiving IPv4 Packets . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Madanapalli & Park Expires August 11, 2007 [Page 2]
Internet-Draft IPv4 over 802.16's IP CS February 2007
1. Introduction
802.16 [6] is a connection oriented access technology for the last
mile without bi-directional native multicast support. 802.16 has only
downlink multicast support and there is no mechanisms defined for
mobile stations to be able to send multicast packets that can be
mapped to downlink multicast connection. And also 802.16 MAC does
not use the Source and Destination MAC addresses, instead it uses the
Connection Identifiers (CIDs), which are assigned dynamically while
setting up the MAC connections, for transmitting the 802.16 frames
between a Mobile Station and a Base Station.
This document specifies a method for encapsulating and transmitting
IPv4 [2] and Address Resolution Protocol (ARP) packets over IP CS of
IEEE 802.16. This document also specifies the MTU and address
assignment method for the 802.16 based networks using IPCS. As the
802.16 MAC does not use the source and destination MAC addresses for
the frame transmission, this document recommends avoiding ARP and
Mapping of multicast IP address to MAC address, and recommends always
assigning a default gateway for the mobile stations.
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 [1].
2. Terminology
The terminology in this document is based on the definitions in [10],
in addition to the ones specified in this section.
Access Router (AR): An entity that performs an IP routing function to
provide IP connectivity for Mobile Stations. In WiMAX Networks, the
AR is an Access Service Network Gateway.
3. Typical Network Architecture for IPv4 over 802.16
In a network that utilizes the 802.16 air interface the 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
Madanapalli & Park Expires August 11, 2007 [Page 3]
Internet-Draft IPv4 over 802.16's IP CS February 2007
illustrates the network architectures.
+-----+ CID1 +------+ +-----------+
| MS1 |----------+| BS |----------| AR |-----[Internet]
+-----+ / +------+ +-----------+
. / ____________
. CIDn / ()__________()
+-----+ / L2 Tunnel
| MSn |-----/
+-----+
Figure 1: Typical Network Architecture for IPv4 over 802.16
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
IPv6 packets are transmitted in Generic 802.16 MAC frames as shown in
the following figure.
Madanapalli & Park Expires August 11, 2007 [Page 4]
Internet-Draft IPv4 over 802.16's IP CS February 2007
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) |
+-+-+-+-+-+-+-+-+
Figure 2: 802.16 MAC Frame Format for IPv4 Packets
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 Length parameter of 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)
Madanapalli & Park Expires August 11, 2007 [Page 5]
Internet-Draft IPv4 over 802.16's IP CS February 2007
+ CRC (4)). The default MTU for IPv4 over 802.16 SHOULD be 1920,
this would accommodate tunneling overhead for delivering the packets
between BS and AR. This size may be reduced or increased by a Path
MTU Discovery [8] or by manual configuration of each MS. The minimum
and maximum MTUs for IPv4 packets over 802.16 with IPv4 CS are 576
bytes and 2038 bytes respectively.
6. IPv4 Address Assignment
DHCP [4] SHOULD be used for assigning IPv4 address for the MSs. DHCP
messages are transported over 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 [5]. The DHCP Relay Agent MUST
store the information on which interface (L2 Tunnel) it has received
the DHCP messages, so that it can relay the DHCP responses to the
correct MS.
7. Address Resolution Protocol
The 802.16 frame header does not contain the source and destination
MAC addresses, instead it uses the Connection Identifier (CID) for
the MAC frames delivery. This makes classical Address Resolution
Protocol (ARP) [3] trivial and unnecessary. If an MS initiates an
ARP for address resolution, the AR SHOULD silently discard the ARP
packet. All the outgoing packets that arrive at IPv4 layer, should
be given to 802.16's IPv4 CS, which would map the packets to
appropriate MAC transport connection.
The AR MUST be configured as the default gateway for the MSs that
have been attached to it. ICMP Router Discovery [9] may be used for
discovering the AR IP address.
8. IP Multicast Address Mapping
Mapping of multicast IP address to a MAC address is not required as
the 802.16 MAC address is not used for delivering the MAC frames.
The 802.16 uses the Connection ID (CID) for frame delivery hence no
address mapping is required.
9. Sending and Receiving IPv4 Packets
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
Madanapalli & Park Expires August 11, 2007 [Page 6]
Internet-Draft IPv4 over 802.16's IP CS February 2007
Ethernet.
Before any packets being transmitted, 802.16 transport connection
must be established. This connection is consists of 802.16 MAC
transport connection between MS and BS and an L2 tunnel between BS
and AR. This 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 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 being 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.
10. Security Considerations
This document specifies transmission of IPv4 packets over 802.16
networks with IPv4 Convergence Sublayer and does not introduce any
new vulnerabilities to IPv4 specifications or operation. The
security of the 802.16 air interface is the subject of [6]. In
addition, the security issues of the network architecture spanning
beyond the 802.16 base stations is the subject of the documents
defining such architectures, such as WiMAX Network Architecture [7].
11. IANA Considerations
This document has no actions for IANA.
Madanapalli & Park Expires August 11, 2007 [Page 7]
Internet-Draft IPv4 over 802.16's IP CS February 2007
12. Acknowledgements
TBD.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[3] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993.
13.2. Informative References
[6] "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.
[7] "WiMAX End-to-End Network Systems Architecture,
http://www.wimaxforum.org/technology/documents", August 2006.
[8] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[9] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[10] Jee, J., "IP over 802.16 Problem Statement and Goals",
October 2006, <http://www.ietf.org/internet-drafts/
draft-ietf-16ng-ps-goals-00.txt>.
Madanapalli & Park Expires August 11, 2007 [Page 8]
Internet-Draft IPv4 over 802.16's IP CS February 2007
Authors' Addresses
Syam Madanapalli
LogicaCMG
Bangalore
India
Email: smadanapalli@gmail.com
Soohong Daniel Park
Samsung Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon 442-742
Korea
Email: soohong.park@samsung.com
Madanapalli & Park Expires August 11, 2007 [Page 9]
Internet-Draft IPv4 over 802.16's IP CS February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Madanapalli & Park Expires August 11, 2007 [Page 10]