Network Working Group J. Jee, Editor
Internet-Draft ETRI
Expires: August 31, 2006 S. Madanapalli
Samsung ISO
J. Mandin
Runcom
G. Montenegro
Microsoft
S. Park
Samsung Electronics
M. Riegel
Siemens
February 27, 2006
IP over 802.16 Problem Statements and Goals
draft-jee-16ng-ps-goals-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 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft provides overview of 802.16 Network characteristics and
Jee, Editor, et al. Expires August 31, 2006 [Page 1]
Internet-Draft IP over 802.16 Problems and Goals February 2006
Convergence Sublayers, and specifies the problems in running the IETF
IP (both IPv4 and IPv6) protocols over 802.16 Networks. This
document also presents the goals that point at relevant work to be at
IETF.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 4
4.1. Transport Connections . . . . . . . . . . . . . . . . . . 5
4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 5
4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 5
5. 16ng Problem Statements . . . . . . . . . . . . . . . . . . . 6
5.1. Root Causes . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. IP over 802.16 with IP CS: Problems . . . . . . . . . . . 7
5.2.1. IPv4 over IP CS . . . . . . . . . . . . . . . . . . . 7
5.2.2. IPv6 over IP CS . . . . . . . . . . . . . . . . . . . 8
5.3. IP over 802.16 with Ethernet CS: Problems . . . . . . . . 9
5.3.1. IPv4 over Ethernet CS . . . . . . . . . . . . . . . . 9
5.3.2. IPv6 over Ethernet CS . . . . . . . . . . . . . . . . 10
6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. IP Link Model . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Jee, Editor, et al. Expires August 31, 2006 [Page 2]
Internet-Draft IP over 802.16 Problems and Goals February 2006
1. Introduction
Broadband Wireless Access networks address the inadequacies of low
bandwidth wireless communication for user requirements such as high
quality data/voice service, fast mobility, wide coverage, etc. The
IEEE 802.16 Working Group on Broadband Wireless Access Standards
develops standards and recommended practices to support the
development and deployment of broadband Wireless Metropolitan Area
Networks [IEEE802.16]. Additionally, IEEE 802.16e is an amendment
that adds support for mobility over the base IEEE 802.16
specification [IEEE802.16e].
Recently, the WiMAX Forum, and, in particular, its NWG (Network
Working Group) is defining the IEEE 802.16(e) network architecture
(e.g., IPv4, IPv6, Mobility, Interworking with different networks,
AAA, etc). The NWG is thus taking on work at layers above those
defined by the IEEE 802 standards (typically limited to the physical
and link layers only). Similarly, WiBro (Wireless Broadband), a
Korean effort which focuses on the 2.3 GHz spectrum band, is also
based on the IEEE 802.16e specification [IEEE802.16e].
IEEE 802.16(e) is different from existing wireless access
technologies such as IEEE 802.11 or 3G. For example: immediately
subsequent to network entry, an 802.16 SS (Subscriber Station) has no
capability whatsoever for data (as opposed to management)
connectivity. The criteria by which the BS (Base Station) sets up
the 802.16 MAC connections for data transport is not part of the
802.16 standard and depends on the type of data services being
offered (ie. the set up of transport connections will be different
for IPv4 and IPv6 services). Additionally - as 802.16 is a point-to-
multipoint network - an 802.16 subscriber station is not capable of
broadcasting (e.g., for neighbor discovery or dynamic address
binding) or direct communication to the other nodes in the network.
This lacking of facility for native multicasting for IP packet
transfer results in inappropriateness to apply the basic IP operation
like IPv4 Address Resolution Protocol or IPv6 Neighbor Discovery
Protocol. Accordingly, while 802.16 defines the encapsulation of an
IP datagram in an IEEE 802.16 MAC payload, complete description of IP
operation is not present. Thus, IP operation over IEEE 802.16 can
benefit from IETF input and specification. Two styles of link layers
are available from 802.16e [IEEE802.16e] as IP CS and Ethernet CS.
Also, WiMAX Forum has decided to make IP CS mandatory for IEEE
802.16e profile, and EthernetCS is an optional. Therefore, the
Ethernet capability layer does not exist in all implementations of
IEEE 802.16e profile. This document will describe the problems
identified in adopting IP over IEEE 802.16 networks. Also several
goals that point at relevant work to be done at IETF are presented
Jee, Editor, et al. Expires August 31, 2006 [Page 3]
Internet-Draft IP over 802.16 Problems and Goals February 2006
subsequently.
2. Requirements
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] .
3. Terminology
Subscriber Station (SS): A generalized equipment set providing
connectivity between subscriber equipment and a base station (BS)
Base Station (BS): A generalized equipment sets providing
connectivity, management, and control of the subscriber station (SS).
IP Gateway: An entity which performs IP routing function to provide
IP connectivity for SSes.
Protocol Data Unit (PDU): This refers to the data format passed from
the lower edge of the 802.16 MAC to the 802.16 PHY, which typically
contains SDU data after fragmentation, encryption, etc.
Service Data Unit (SDU): This refers to the data format passed to the
upper edge of the 802.16 MAC
IP Link : This has the same meaning with the "IP Subnet" in case of
IPv4. This terminology represents both IPv6 link and IPv4 subnet
throughout this document. Under the same IP Link, a specific SS can
communicate with its communication peer without depending on the IP
routing facility. SSes under the same IP link share the same IP
network information, IPv4 subnet address or IPv6 link prefix.
4. Overview of the IEEE 802.16-2004 MAC layer
The topology of the IEEE 802.16-2004 [IEEE802.16] network is point-
to-multipoint (PMP): a Base Station (BS) communicates with a number
of Subscriber Stations (SSes). Each node in the network possesses a
48-bit MAC address (though in the Base Station this 48-bit unique
identifier is called "BSId"). Each node possesses RSA-based
authorization mechanism using x.509 certificate attesting to its MAC
address/BSId. The [IEEE802.16e] enhanced RSA-based authorization and
developed EAP-based authentication defined in [RFC3748] accordingly.
So EAP-based authentication is recommended for mobile user. The BS
and SS learn each others' MAC Address/BSId during the SS's entry into
Jee, Editor, et al. Expires August 31, 2006 [Page 4]
Internet-Draft IP over 802.16 Problems and Goals February 2006
the network.
4.1. Transport Connections
User data traffic (in both the BS-bound and SS-bound directions) is
carried on unidirectional "transport connections". Each transport
connection has a particular set of associated parameters indicating
characteristics such as cryptographic suite and quality-of-service.
After successful entry of a SS to the 802.16 network, no data traffic
is possible - as there are as yet no transport connections between
the BS and SS. Transport connections are established by a 3-message
signaling sequence within the MAC layer (usually initiated by the
BS).
A downlink-direction transport connection is regarded as "multicast"
if it has been made available (via MAC signaling) to more than one
SS. Uplink-direction connections are always unicast.
4.2. 802.16 PDU format
An 802.16 PDU (ie. the format that is transmitted over the airlink)
consists of a 6-byte MAC header, various optional subheaders, and a
data payload.
The 802.16 6-byte MAC header carries the Connection Identifer (CID)
of the connection with which the PDU is associated. We should
observe that there is no source or destination address present in the
raw 802.16 MAC header.
4.3. 802.16 Convergence Sublayer
The 802.16 convergence sublayer (CS) is the component of the MAC that
is responsible for assigning transmit-direction SDUs (originating
from a higher layer application - eg. an IP stack at the BS or SS) to
a specific outbound transport connection. The convergence sublayer
maintains an ordered "classifier table". Each entry in the
classifier table includes a classifier and a target CID. A
classifier, in turn, consists of a conjunction of one or more
subclassifiers - where each subclassifier specifies a packet field
(eg. the destination MAC address in an Ethernet frame, or the TOS
field of an IP datagram contained in an Ethernet frame) together with
a particular value or range of values for the field. To perform
classification on an outbound SDU, the convergence sublayer proceeds
from the first entry of the classifier table to the last, and
evaluates the fields of the SDU for a match with the table entry's
classifier When a match is found, the convergence sublayer associates
the SDU with the target CID (for eventual transmission), and the
Jee, Editor, et al. Expires August 31, 2006 [Page 5]
Internet-Draft IP over 802.16 Problems and Goals February 2006
remainder of the 802.16 MAC and PHY processing can take place.
802.16 define numerous convergence sublayer types. The "type" of the
convergence sublayer determines the fields that may appear in
classifiers eg.
o "802.3/Ethernet CS" permits classifiers that examine fields in
802.3-style headers
o "IPv4 CS" permits classifiers that examine fields of IPv4 (and
encapsulated TCP/ UDP headers)
o "IPv6 CS" permits classifiers that examine fields of IPv6 (and
encapsulated TCP/ UDP headers)
Other CS types include ATM, IPv4-over-ethernet CS and IPv6-over-
ethernet CS. An implementation of 802.16 can support multiple CS
types.
We can observe that the CS type actually defines the type of data
interface (eg. IPv4/IPv6 or 802.3 ) that is presented by 802.16 to
the higher layer application.
5. 16ng Problem Statements
5.1. Root Causes
This section describes common problem statements regardless of
convergence sublayer.
The following are the root causes that prevent running IP protocols
(both IPv4 and IPv6) over 802.16 networks smoothly. The consequences
of these characteristics are listed in Section 5.2 and 5.3.
- Point-to-Multipoint architecture:
The 802.16 is a point-to-multipoint network without bi-directional
native multicast support. This prevents IP nodes from multicasting.
In 802.16 specification, when the 802.16 MAC receives a unicast/
multicast/broadcast packet from upper Layers, it just looks at the
various fields (classifiers) in the headers and maps to the outgoing
CID (This can also be a multicast CID in case of downlink).
When 802.16 MAC receives a PDU from the PHY, it simply passes it to
the layer above the MAC (eg. Ethernet or IP). It is the upper
layer's responsibility to deliver the packet to the correct
destination which nonetheless is limited by the existence of downlink
Jee, Editor, et al. Expires August 31, 2006 [Page 6]
Internet-Draft IP over 802.16 Problems and Goals February 2006
multicast/broadcast connections for multicast/broadcast frames.
Because IP layer services (e.g. IPv4 ARP, DHCPv4, IPv6 NDP, DHCPv6
etc.) rely on link-layer multicast--or services with similar
semantics at the link-layer--, alternative mechanisms must be
specified.
- Limitation of Ethernet capability layer of 802.16:
The Ethernet capability layer of 802.16 (called the convergence
sublayer) specifies only how Ethernet frames are to be encapsulated
over 802.16 wireless connections. This demonstrates that Ethernet CS
does not itself emulate Ethernet like functionality, and multicast/
broadcast frames can not be processed at the 802.16 MAC layer only.
These frames must be sent to an Ethernet/bridge layer, which in turn
may send PDUs back to 802.16 downlink, to send out these multicast/
broadcast frames there should be a downlink multicast/broadcast
connection to which all SSes are listening.
- Communication among SSes on the same IP link:
It is unclear in 802.16 networks how SSes under a certain IP gateway
communicate each other under the assumption that they are in same IP
Link. In IPv6 case, [I-D.ietf-ipv6-2461bis] defines IP Link as a
communication facility or medium over which nodes can communicate at
the link layer, i.e., the layer immediately below IP. Examples are
Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM
networks as well as internet (or higher) layer "tunnels", such as
tunnels over IPv4 or IPv6 itself. The 802.16 network has a
connection oriented feature, where a connection always ends at the
BS. There is no support from 802.16 MAC/PHY for the direct
communication among SSes under the same IP link. The issue of
configuring an "IP Link" over IEEE 802.16 network is described in the
Appendix A.
5.2. IP over 802.16 with IP CS: Problems
5.2.1. IPv4 over IP CS
- DHCPv4 IP Address management and assignment:
For the IPv4 address management and assignment, IEEE 802.16 network
refers primarily to allocation of Dynamic Host Configuration Protocol
[RFC2131], static method is configured by manual though. DHCPv4 is a
broadcasting-based IP allocation protocol. When initializing its IP
configuration, the SS broadcasts a DHCPDISCOVER message on its local
physical subnet. After receiving multiple DHCPOFFER messages, the SS
broadcasts a DHCPREQUEST message with several options specifying
desired configuration values. However, current DHCPv4 operations are
Jee, Editor, et al. Expires August 31, 2006 [Page 7]
Internet-Draft IP over 802.16 Problems and Goals February 2006
tricky because of IEEE 802.16 non-broadcasting characteristics.
Especially, DHCPv4 operation is tightly related to ARP facilities
(e.g., checking on the uniqueness of allocated network address,
etc.). For management and configuration requirements of SS, an IETF-
based IP address allocation solutions should be specified in
compliance with IEEE 802.16(e) networks. In DHCPv6 [RFC3315] case,
it is modeled on DHCPv4, so, the problems described above still
remain. For MIP-based mobile terminals, MIPv4 [RFC3344] based IP
addressing is used instead of DHCPv4. However, it still requires
multicast/broadcast facilities for supporting ICMP Router
Advertisement [RFC1256].
- ARP resolution and ARP cache:
Address Resolution is the process by which nodes determine the link-
layer address of a destination node on the same subnet given only the
destination's IP address and it is a mandatory function of TCP/IP.
In IPCS case, however, there is no need for address resolution
because MAC message is made by IP Gateway instead of SS and hence ARP
cache as 802.16 MAC address is never used as part of the 802.16
Frame. Blocking ARP needs to be implemented by SS itself in an
implementation manner. There is no way of how to use ARP facilities
on SS.
5.2.2. IPv6 over IP CS
- Router Discovery:
Because there is no MAC Address used in case of IPCS, it is unclear
whether source link layer address need to be carried in the RS
(Router Solicitation). As 802.16 MAC Address is not used for
delivering the frames the RS may need to have source IP address
specified, so that the RA (Router Advertisement) can be sent back.
This may require the completion of Link Local Address configuration
before sending an RS.
For sending periodic Router Advertisements in 802.16 Networks, BS
either needs to send the RA in unicast manner for each SS explicitly
or send the RA in multicast connection.
- Prefix Assignment:
If the same IP prefix is shared with multiple SSes then the link
consists of multiple SSes. In this model a SS assumes that there
exist on-link neighbors and tries to resolve the L2 address for the
on-link prefixes. However, direct communication using Link Layer
Address between two SSs may not be possible. This poses a problem
for sharing a prefix with multiple SSes.
Jee, Editor, et al. Expires August 31, 2006 [Page 8]
Internet-Draft IP over 802.16 Problems and Goals February 2006
- Address Resolution and Neighbor Cache:
Address Resolution is the process by which nodes determine the link-
layer address of an on-link destination (e.g., a neighbor) given only
the destination's IP address. In case of IP CS, there is no need for
Address Resolution and hence Neighbor Cache as 802.16 MAC address is
never used as part of the 802.16 Frame.
- Neighbor Unreachability Detection (NUD):
In case of IP CS, a SS may always see the IP Gateway as the next hop,
the NUD is required only for the IP Gateway(s). Also the requirement
of NUD may depend on the existence of a connection to the BS for that
particular destination. If there exists multiple IP Gateways (so the
default routers), it is unknown if the NUD is required if an IP
Gateway is not serving any 802.16 MAC connection.
- Address Autoconfiguration:
How Address Autoconfiguration can be achieved in 802.16 networks is
dependent on following: 1) Whether the SSes attached to the same BS
are neighbors (IP link Model), 2) Whether the prefix is being shared
with other SSes. If a unique prefix is assigned to each SS similar
to 3G approach, then the subnet consists of only one SS and hence
duplicate address detection (DAD) is trivial. If the same prefix is
shared with multiple SSes then the subnet consists of multiple SSes
and DAD is required. DAD in 802.16 requires explicit multicast
support from the Networks as there is no native multicast support.
Thus, the explicit mechanism to perform the DAD procedure in the
802.16 network needs to be specified.
5.3. IP over 802.16 with Ethernet CS: Problems
We assume that the IP gateway supports Ethernet interface and the IP
Gateway sees the Ethernet frame sent by the SS unchanged.
5.3.1. IPv4 over Ethernet CS
DHCPv4 IP Address management and assignment:
In the Ethernet CS case, the SS act as a layer 2 device and IP
assignment will be carried through for hosts behind the BS. In this
case, the BS simply forwards the DHCPv4 messages between the DHCPv4
client and DHCPv4 server. However, as pointed out in above, Ethernet
CS is an optional function over IEEE 802.16 networks, so it can not
be applied for all SSes and limitation of DHCPv4 still remains.
- ARP resolution and ARP cache:
Jee, Editor, et al. Expires August 31, 2006 [Page 9]
Internet-Draft IP over 802.16 Problems and Goals February 2006
Address Resolution is the process by which nodes determine the link-
layer address of a destination node on the same subnet given only the
destination's IP address and it is a mandatory function of TCP/IP.
In Ethernet CS case, if ARP is blocked by SS like IPCS, there is no
way to obtain the MAC address of IP Gateway without ARP process
because SS have to generate its ARP request message by itself. There
is no way of how to use ARP facilities on SS.
5.3.2. IPv6 over Ethernet CS
- Router Discovery:
For sending periodic Router Advertisements in 802.16 Networks, BS
either needs to send the RA in unicast manner for each SS explicitly
or send the RA through the multicast connection if available.
- Prefix Assignment:
Similar to IP CS case.
- Address Resolution and Neighbor Cache:
In case of Ethernet CS, if the prefix is shared with L-bit set, the
Address Resolution may be required, which in turn requires multicast
support from 802.16 MAC. If the prefixes are advertised with L bit
reset, then Address Resolution and Neighbor Cache for other SSes may
not be required. In this case, Neighbor Cache is maintained only for
IP Gateway.
- Neighbor Unreachability Detection (NUD):
Same as IP CS case.
- Address Autoconfiguration:
Same as IP CS case.
6. Gap Analysis
This section analyzes gaps between 802.16 networks and possible
alternative approaches.
3GPP recommendation [RFC3314]:
From the 3GPP recommendation, separate prefixes are allocated to each
SSes resulting in the different IP links for each SSes. IP Gateway
might be comparable to the GGSN of 3GPP network. However, using PPP
Jee, Editor, et al. Expires August 31, 2006 [Page 10]
Internet-Draft IP over 802.16 Problems and Goals February 2006
directly is not feasible in 802.16 networks because there is no PPP
Convergence Sublayer that permits classification to transport
connections based on fields in a PPP header. Moreover, more
preferable way is to configure a common IP link for all SSes under an
ASN IP Gateway. Thus, how to form a common IP link for all SSes
under a certain IP Gateway needs to be focused.
LAN model [RFC0894]:
It seems easy to follow the LAN model where BS and IP Gateway reside
on the same box. However, the BS implementation to emulate a LAN
feature would be different from the previous Wireless LAN bridge. In
802.16, BS does not directly see the destination Ethernet address to
forward the layer 2 frame. The MAC common part needs to deliver the
MAC SDU to the convergence sublayer to be classified to the
confirming MAC connection. We can also recognize the different point
from the Wireless LAN bridge. Mostly AP in the wireless LAN
translates the 802.11 frame to 802.3 frame by the help of the
existence of same LLC. However, there is no LLC in the 802.16
protocol stack thus, it is problematic to convert 802.16 frame to
802.3 frame directly. Thus, in 802.16, it is expected that MAC
common layer of 802.16 to deliver the MAC SDU to the upper packet
convergence sublayer to reconstruct the higher layer PDU to classify
to the confirming connection.
7. Goals
We need to first identify which "IP Link" model is a feasible one
depending on each CS is used. According to the identified "IP Link"
model for each CS, we would specify the following work items.
* IPv4 transmission for 802.16 network in case where IPv4 CS is used.
* IPv4 transmission for 802.16 network in case where Ethernet CS is
used.
* IPv6 transmission for 802.16 network in case where IPv6 CS is used.
* IPv6 transmission for 802.16 network in case where Ethernet CS is
used.
The following are the goals in no particular order that point at
relevant work to be done in IETF.
1. The solution SHOULD work with the existing or normal IP host
implementations.
Jee, Editor, et al. Expires August 31, 2006 [Page 11]
Internet-Draft IP over 802.16 Problems and Goals February 2006
2. In case where Ethernet CS is used for multiple interface hosts,
it is desirable to provide a single host stack that could work
without depending on the specific media characteristic.
3. It SHOULD be specified which connection (Secondary Management or
a new IP signaling connection) an SS should use to send ICMP
messages. One possible way of implementing IP signaling such as ICMP
(and even IPv6 ND) is to use 802.16/16e transport connection rather
than secondary management connection. In this implementation, one IP
layer broadcast/multicast packet which needs to be delivered to a
specific SS can be delivered to the SS based on demand. For example,
if the IP Gateway which is co-located with IPv4 Foreign Agent needs
to transfer Agent Advertisement to SS, unicast transport connection
between BS and SS can be used.
4. It is desirable to have a model for multicast/broadcast support
in 802.16 so that an SS can send a multicast packet to all SSes
within an IP Link. There should also be an option to turn off this
facility in cases where it is not required or undesirable.
5. The solution SHOULD avoid using the air bandwidth wherever
possible.
6. The solution SHOULD not introduce any new security threats.
8. Security Considerations
As described in the section 4, several authentication and
authorization mechanisms are defined by [IEEE802.16] and
[IEEE802.16e]. In [IEEE802.16e] case, PKMv2 EAP-based authentication
is recommended for the secure connection between SS and BS/IP
Gateway.
9. IANA Considerations
No new protocol numbers are required.
10. Acknowledgment
We would like to express special thanks to IETF Mobility Working
Group members of KWISF (Korea Wireless Internet Standardization
Forum) for their initial efforts and remarkably to HeeYoung Jung for
his motivation in proceeding this work.
We also would like to express special thanks to the previous authors
Jee, Editor, et al. Expires August 31, 2006 [Page 12]
Internet-Draft IP over 802.16 Problems and Goals February 2006
of the previous problem statement document, Myung-Ki Shin, Eun-Kyoung
Paik and Jaesun Cha.
We also would like to express thanks to Jicheol Lee, Sung Il Kim, Se
Jun Park, Sang Eon Kim, Han-Lim Kim and Jung-Mo Moon for their inputs
to this work.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-05 (work in progress),
October 2005.
[IEEE802.16]
IEEE Std 802.16-2004, "IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", October 2004.
[IEEE802.16e]
IEEE P802.16e-2005, "Draft IEEE Standard for Local and
metropolitan area networks, Amendment for Physical and
Medium Access Control Layers for Combined Fixed and
Mobile Operation in Licensed Bands", 2005.
[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.
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams
over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Jee, Editor, et al. Expires August 31, 2006 [Page 13]
Internet-Draft IP over 802.16 Problems and Goals February 2006
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
Appendix A. IP Link Model
[I-D.ietf-ipv6-2461bis] defines IP Link as a communication facility
or medium over which nodes can communicate at the link layer, i.e.,
the layer immediately below IP. Examples are Ethernets (simple or
bridged), PPP links, X.25, Frame Relay, or ATM networks as well as
internet (or higher) layer "tunnels", such as tunnels over IPv4 or
IPv6 itself. 802.16 connection oriented technology but the connection
always ends at Base Station unlike in NBMA technologies (e.g. ATM
and Frame Relay) where connections exist between peer entities.
Because of this characteristic, it is also unclear how two nodes
connected to two different base stations communicate each other under
the assumption that they are in same IP Link. As 802.16 MAC/PHY is
not used to communicate directly between to nodes the definition of
IP Link in 802.16 is unclear.
Depending on the use of Convergence Sublayer, prefix assignment and
the preference of operators, there can be three different types of
subnet IP link models.
- The IP link consisting of multiple BSes and all the SSes hanging
off them with multiple IP Gateways.
- The IP link consisting of multiple BSes and all the SSes hanging
off it with single IP Gateway.
- The IP link consisting of just the point to point connectivity
between an IP Gateway and one SS.
Jee, Editor, et al. Expires August 31, 2006 [Page 14]
Internet-Draft IP over 802.16 Problems and Goals February 2006
Authors' Addresses
Junghoon Jee
ETRI
Email: jhjee@etri.re.kr
Syam Madanapalli
Samsung ISO
Email: syam@samsung.com
Jeff Mandin
Runcom
Email: jeff@streetwaves-networks.com
gabriel_montenegro_2000@yahoo.com
Microsoft
Email: gabriel_montenegro_2000@yahoo.com
Soohong Daniel Park
Samsung Electronics
Email: soohong.park@samsung.com
Maximilian Riegel
Siemens
Email: maximilian.riegel@siemens.com
Jee, Editor, et al. Expires August 31, 2006 [Page 15]
Internet-Draft IP over 802.16 Problems and Goals February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jee, Editor, et al. Expires August 31, 2006 [Page 16]