One document matched: draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07.txt
Differences from draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06.txt
16ng Working Group S. Madanapalli
Internet-Draft Ordyn Technologies
Intended status: Standards Track Soohong D. Park
Expires: December 4, 2010 Samsung Electronics
S. Chakrabarti
IP Infusion
G. Montenegro
Microsoft Corporation
June 2, 2010
Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-07
Abstract
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).
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 4, 2010.
Copyright Notice
Madanapalli, et al. Expires December 4, 2010 [Page 1]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Madanapalli, et al. Expires December 4, 2010 [Page 2]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Typical Network Architecture for IPv4 over IEEE 802.16 . . . . 4
3.1. IEEE 802.16 IPv4 Convergence Sublayer Support . . . . . . 4
4. IPv4 CS link in 802.16 Networks . . . . . . . . . . . . . . . 5
4.1. IPv4 CS link establishment . . . . . . . . . . . . . . . . 5
4.2. Frame Format for IPv4 Packets . . . . . . . . . . . . . . 5
4.3. Maximum Transmission Unit . . . . . . . . . . . . . . . . 6
5. Subnet Model and IPv4 Address Assignment . . . . . . . . . . . 8
5.1. IPv4 Unicast Address Assignment . . . . . . . . . . . . . 9
5.2. Address Resolution Protocol . . . . . . . . . . . . . . . 9
5.3. IP Broadcast and Multicast . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Multiple Convergence Layers - Impact on Subnet
Model . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Sending and Receiving IPv4 Packets . . . . . . . . . 11
Appendix C. WiMAX IPCS MTU size . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Madanapalli, et al. Expires December 4, 2010 [Page 3]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
1. Introduction
IEEE 802.16 [IEEE802_16] 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
[IEEE802_16].
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.
This document specifies a method for encapsulating and transmitting
IPv4 [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.
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].
2. Terminology
o 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.
Other terminology in this document is based on the definitions in
[RFC5154].
3. Typical Network Architecture for IPv4 over IEEE 802.16
The network architecture follows what is described in [RFC5154] and
[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).
For further information on the typical network architecture, see
[RFC5121] section 5.
3.1. IEEE 802.16 IPv4 Convergence Sublayer Support
As described in [IEEE802_16], the IP-specific part of the packet CS
allows the transmission of either IPv4 or IPv6 payloads. In this
Madanapalli, et al. Expires December 4, 2010 [Page 4]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
document, we are focusing on the IPv4 over Packet Convergence
Sublayer.
For further information on the IEEE 802.16 Convergence Sublayer and
encapsulation of IP packets, see [RFC5121] section 4 and
[IEEE802_16].
4. IPv4 CS link in 802.16 Networks
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.
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.
Each host belongs to a different IPv4 link and is assigned an unique
IPv4 address per recommendations in [RFC4968].
4.1. IPv4 CS link establishment
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 [RFC5121]. Steps
1-4 are same as indicated in 6.2 of [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.
4.2. Frame Format for IPv4 Packets
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 [RFC5154] ).
Madanapalli, et al. Expires December 4, 2010 [Page 5]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
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 1: IEEE 802.16 MAC Frame Format for IPv4 Packets
Here, "MSB" means "most significant byte", and "LSB" means "least
significant byte".
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 = 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
4.3. Maximum Transmission Unit
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).
Madanapalli, et al. Expires December 4, 2010 [Page 6]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
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 [RFC4459].
Per [RFC5121] section 6.3, the IP MTU can vary to be larger or
smaller than 1500 octets.
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.
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.
Some of the mechanisms available for the IPv4 CS host to find out
Madanapalli, et al. Expires December 4, 2010 [Page 7]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
the link's MTU value and mitigate MTU-related issues are:
o The IEEE recently revised 802.16 (see IEEE 802.16-2009
[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.
o Configuration and negotiation of MTU size at the network layer by
using the DHCP interface MTU option [RFC2132].
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.
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[IEEE802_16].
Additionally, the clients are encouraged to run PMTU [RFC1191] or
PPMTUD [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.
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.
Madanapalli, et al. Expires December 4, 2010 [Page 8]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
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.
6. 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
[IEEE802_16]. 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 [WMF].
7. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
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
Madanapalli, et al. Expires December 4, 2010 [Page 9]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
document to make it better.
9. References
9.1. Normative References
[IEEE802_16]
"IEEE Std 802.16-2009, Draft Standard for Local and
Metropolitan area networks, Part 16: Air Interface for
Broadband Wireless Access Systems", May 2009.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0826] 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.
[RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, October 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
9.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple
Encapsulation Methods Considered Harmful", RFC 4840,
April 2007.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Madanapalli, et al. Expires December 4, 2010 [Page 10]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
Based Networks", RFC 4968, August 2007.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE
802.16 Problem Statement and Goals", RFC 5154, April 2008.
[WMF] "WiMAX End-to-End Network Systems Architecture Stage 2-3
Release 1.2, http://www.wimaxforum.org/", January 2008.
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 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 [RFC4840].
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 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.
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.
The BS optionally reconstructs the payload header if PHS is in use.
Madanapalli, et al. Expires December 4, 2010 [Page 11]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
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.
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.
Appendix C. WiMAX IPCS MTU size
WiMAX (Worldwide Interoperability for Microwave Access) forum has
defined a network architecture [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 [WMF] has specified the IP MTU as 1400 octets
[WMF] as opposed to 1500 in this specification.
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.
Madanapalli, et al. Expires December 4, 2010 [Page 12]
Internet-Draft IPv4 over IEEE 802.16's IPv4 CS June 2010
Authors' Addresses
Syam Madanapalli
Ordyn Technologies
1st Floor, Creator Building, ITPL
Bangalore - 560066
India
Email: smadanapalli@gmail.com
Soohong Daniel Park
Samsung Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon 442-742
Korea
Email: soohong.park@samsung.com
Samita Chakrabarti
IP Infusion
1188 Arques Avenue
Sunnyvale, CA
USA
Email: samitac@ipinfusion.com
Gabriel Montenegro
Microsoft Corporation
Redmond, Washington
USA
Email: gabriel.montenegro@microsoft.com
Madanapalli, et al. Expires December 4, 2010 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 10:53:22 |