Network Working Group J. Jee, Editor
Internet-Draft ETRI
Intended status: Standards Track S. Madanapalli
Expires: August 19, 2007 LogicaCMG
J. Mandin
Runcom
G. Montenegro
Microsoft
S. Park
Samsung Electronics
M. Riegel
Siemens
February 15, 2007
IP over 802.16 Problem Statement and Goals
draft-ietf-16ng-ps-goals-01.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 19, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies problems in running the IETF IP protocols
Jee, Editor, et al. Expires August 19, 2007 [Page 1]
Internet-Draft IP over 802.16 PS and Goals February 2007
over IEEE 802.16 networks by identifying specific gaps in the 802.16
MAC for IPv4 and IPv6 support. This document also provides an
overview of IEEE 802.16 network characteristics and convergence
sublayers. The common terminology to be used for the base guideline
while defining the solution frameworks is also presented.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 5
4.1. Transport Connections . . . . . . . . . . . . . . . . . . 5
4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 6
4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 6
5. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 8
5.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Point-to-Point Link model for IP CS: Problems . . . . . . 9
5.3. Ethernet like Link model for Ethernet CS: Problems . . . . 10
5.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Jee, Editor, et al. Expires August 19, 2007 [Page 2]
Internet-Draft IP over 802.16 PS and Goals February 2007
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].
Recently, the WiMAX Forum, and, in particular, its NWG (Network
Working Group) is defining the IEEE 802.16 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.16 specification [IEEE802.16].
802.16 [IEEE802.16] is point-to-point and connection-oriented at the
MAC, physically arranged in a point-to-multipoint structure with the
BS terminating one end of each connection and an individual SS
terminating the other end of each connection. The 802.16 convergence
sublayer (CS) is at the uppermost of the MAC that is responsible for
assigning transmit-direction SDUs (originating from a higher layer
application - eg. an IP or Ethernet at the BS or SS) to a specific
outbound transport connection. 802.16 defines two convergence
sublayer types, the ATM CS and the Packet CS. The IP Specific
Subpart (IP CS) and the 802.3 Ethernet Specific Subpart (Ethernet CS)
of Packet CS are within the current 16ng WG scope.
There exists complexity in configuring the IP Subnet over IEEE 802.16
network because of its point-to-point connection oriented feature and
the existence of IP CS and Ethernet CS which assume different higher
layer functionality. IP Subnet is a topological area that uses the
same IP address prefix where that prefix is not further subdivided
except into individual addresses as specified from
[I-D.thaler-intarea-multilink-subnet-issues]. The IP Subnet
configuration is dependent on the underlying link layer's
characteristic and decides the overall IP operation on the network.
The IP CS and Ethernet CS of IEEE 802.16 assume different higher
layer capability, like the IP routing functionality in case of IP CS
and the bridging functionality in case of Ethernet CS. This means
that underlying link layer's characteristics beneath IP can change
according to the adopted convergence sublayers.
This document provides the feasible IP Subnet model for each IP CS
and Ethernet CS and specifies the problems in running IP protocols
Jee, Editor, et al. Expires August 19, 2007 [Page 3]
Internet-Draft IP over 802.16 PS and Goals February 2007
for each case. This document also presents an overview of 802.16
network characteristics specifically focusing on the convergence
sublayers and the common terminology to be used for the base
guideline while defining solution frameworks.
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): An end-user equipment that provides
connectivity to the 802.16 networks. It can be either fixed/nomadic
or mobile equipment. In mobile environment, SS represents the Mobile
Subscriber Station (MS) introduced in [IEEE802.16e].
Base Station (BS): A generalized equipment sets providing
connectivity, management, and control between the subscriber station
and the 802.16 networks.
Access Router (AR): An entity that performs an IP routing function to
provide IP connectivity for subscriber station (SS or MS).
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 Subnet: Topological area that uses the same IP address prefix
where that prefix is not further subdivided except into individual
addresses as specified from
[I-D.thaler-intarea-multilink-subnet-issues].
Link: Topological area bounded by routers which decrement the IPv4
TTL or IPv6 Hop Limit when forwarding the packet as specified from
[I-D.thaler-intarea-multilink-subnet-issues].
Transport Connection: The MAC layer connection in 802.16 between a
SS(MS) and BS with a specific QoS attributes. Several types of
connections are defined and these include broadcast, unicast and
multicast. Each transport connection is uniquely identified by a 16-
bit connection identifier (CID). A transport connection is a unique
Jee, Editor, et al. Expires August 19, 2007 [Page 4]
Internet-Draft IP over 802.16 PS and Goals February 2007
connection intended for user traffic. The scope of the transport
connection is between the SS(MS) and the BS.
Dormant mode: A state in which a subscriber station, especially
mobile station, restricts its ability to receive normal IP traffic by
reducing monitoring of radio channels. This allows the mobile
station to save power and reduces signaling load on the 802.16
network. In the dormant mode, the mobile station is only listening
at scheduled intervals to the paging channel. The 802.16 network
(e.g. Access Router) maintains state about a mobile station which
has transitioned to dormant mode and can page it when needed.
Connection Identifier (CID): A 16-bit value that identifies a
connection to equivalent peers in the 802.16 MAC of the SS(MS) and
BS.
Ethernet CS: It means 802.3/Ethernet CS specific part of the Packet
CS defined in 802.16 STD.
802.1Q CS: It means 802.1Q (VLAN) specific part of the Packet CS
defined in 802.16 STD.
IP CS: It means IP specific subpart of the Packet CS defined in
802.16 STD.
IPv4 CS: It means IP specific subpart of the Packet CS, Classifier 1
(Packet, IPv4)
IPv6 CS: It means IP specific subpart of the Packet CS, Classifier 2
(Packet, IPv6).
4. Overview of the IEEE 802.16-2004 MAC layer
802.16 [IEEE802.16] is point-to-point and connection-oriented at the
MAC, physically arranged in a point-to-multipoint structure with the
BS terminating one end of each connection and an individual SS
terminating the other end of each connection. Each node in the
network possesses a 48-bit MAC address (though in the Base Station
this 48-bit unique identifier is called "BSId"). The BS and SS learn
each others' MAC Address/BSId during the SS's entry into 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.
Jee, Editor, et al. Expires August 19, 2007 [Page 5]
Internet-Draft IP over 802.16 PS and Goals February 2007
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 Generic MAC header, various optional subheaders, and a
data payload.
The 802.16 Generic MAC header carries the Connection Identifier (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
remainder of the 802.16 MAC and PHY processing can take place.
802.16 define two convergence sublayer types, the ATM CS and the
Packet CS. The ATM CS support ATM directly. The Packet CS is
subdivided into three specific subparts.
o "The IP Specific Subpart" carries IP packets over a point-to-point
connection.
Jee, Editor, et al. Expires August 19, 2007 [Page 6]
Internet-Draft IP over 802.16 PS and Goals February 2007
o "The 802.3 Ethernet Specific Subpart" carries packets encoded in
the 802.3/Ethernet packet format with 802.3 style headers.
o "The 802.1Q VLAN Specific Subpart" carries 802 style packets that
contain 802.1Q VLAN Tags.
Classifiers applied to connections at the time of connection
establishment further classifies and subdivides the nature of the
traffic over a connection.
The classifications that apply to the Ethernet CS include packet over
the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the
802.3/Ethernet CS, 802.3/Ethernet CS with ROHC header compression and
802.3/Ethernet with ECRTP header compression.
The classifications that apply to the 802.1Q/VLAN CS include IPv4
over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN.
It should be noted that while the 802.3/Ethernet CS has a packet
classification that does not restrict the IP version (packet over the
802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP
classifiers for those CSs are either IPv4 or IPv6.
The classifiers enable the MAC to be sure of the presence of fields
in the headers and so to be able to apply the payload header
suppression (PHS) feature of 802.16 to those headers.
For the sake of brevity in this document, the following naming
conventions will be used for particular classifications of particular
subparts of particular CSs.
o IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet,
IPv4)
o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet,
IPv6)
o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3
(Packet, 802.3/Ethernet)
An implementation of 802.16 can support multiple CS types.
We can observe that the CS type, subpart and classification actually
defines the type of data interface (eg. IPv4/IPv6 or 802.3) that is
presented by 802.16 to the higher layer application.
Jee, Editor, et al. Expires August 19, 2007 [Page 7]
Internet-Draft IP over 802.16 PS and Goals February 2007
5. IP over IEEE 802.16 Problem Statement and Goals
5.1. Root Problem
The key issue when deploying IP over IEEE 802.16 network is how to
configure an IP Subnet over that link which is connection-oriented
and point-to-point manner in the MAC level. IP Subnet is a
topological area that uses the same IP address prefix where that
prefix is not further subdivided except into individual addresses.
[I-D.thaler-intarea-multilink-subnet-issues] There are three
different IP Subnet models [I-D.ietf-16ng-ipv6-link-model-analysis]
that are possible for 802.16 network:
1) Point-to-point Link Model
2) Ethernet like Link Model
3) Shared IPv6 Prefix Link Model
The specific problems and issues when adopting the above IP Subnet
models to the IEEE 802.16 network are like below:
In the first point-to-point link model, each SS under a BS resides on
the different IP Subnets. Therefore, only a certain SS and an AR
exist under an IP Subnet and IP packets with destination address of
link local scope are delivered only within the point-to-point link
between a SS and an AR. The PPP [RFC1661] has been widely used for
this kind of point-to-point link. However, the direct use of PPP is
not possible on the 802.16 network because the 802.16 does not define
a convergence sublayer which can encapsulate and decapsulate PPP
frames. Therefore, there needs a mechanism to provide a point-to-
point link between a SS and an AR in case of IP CS. The other
alternative is to utilize the the PPP over Ethernet by using the
Ethernet CS. However, Ethernet CS assumes the upper layer's bridging
functionality to realize the Ethernet like link model.
In the second Ethernet like link model, all SSs under an AR reside on
the same IP Subnet. This also applies when SSs are connected with
different BSs. This Ethernet like link model assumes that underlying
link layer provides the equivalent functionality like Ethernet, for
example, native broadcast and multicast. It seems feasible to apply
the 802.16's Ethernet CS to configure this link model. However,
there exists a discrepancy between the assumption from the Ethernet
like link model and the 802.16's MAC feature which is connection-
oriented and not providing multicast and broadcast connection for IP
packet transfer. Moreover, the frequent IP multicast and broadcast
signaling within the IP subnet like Ethernet results in the problem
of waking up dormant SSs.
Jee, Editor, et al. Expires August 19, 2007 [Page 8]
Internet-Draft IP over 802.16 PS and Goals February 2007
The last shared IPv6 prefix link model eventually results in multi-
link subnet problems [I-D.thaler-intarea-multilink-subnet-issues].
In 802.16, BS assigns separate 802.16 connections for SSs.
Therefore, SSs are placed on the different links. In this situation,
distributing shared IPv6 prefix for SSs which are placed on the
different links causes the multi-link subnet problems. This is valid
for IP CS and even to the Ethernet CS if any bridging functionality
is not implemented on top of BS or between BS and AR.
We identified the feasible IP Subnet models for IEEE 802.16 networks
depending on the convergence sublayers. At the current stage, only
the IP CS and Ethernet CS of IEEE 802.16 are within the 16ng scope.
Followings are the feasible IP Subnet models for each convergence
sublayer used.
1. Point-to-Point Link model for IP CS.
2. Ethernet like Link Model for Ethernet CS.
According to the point-to-point feature of 802.16's MAC, the Point-
to-Point link model is the feasible IP Subnet model for IP CS under
considering the multilink subnet problems. For the Ethernet CS, the
Ethernet like link model is the feasible IP Subnet model. However,
in this model unnecessary multicast and broadcast packets within an
IP Subnet should be minimized.
5.2. Point-to-Point Link model for IP CS: Problems
- Address Resolution:
Address Resolution is the process by which IP nodes determine the
link- layer address of a destination node on the same IP Subnet given
only the destination's IP address. In IP CS case, however, there is
no need for address resolution because ARP cache or Neighbor cache as
802.16 MAC address is never used as part of the 802.16 frame.
Blocking ARP or the address resolution of NDP needs to be implemented
by SS itself in an implementation manner.
-Router Discovery:
Because MAC address is not used for transmission in case of IP CS, it
is unclear whether source link layer address need to be carried in
the RS (Router Solicitation). 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 the link local address
configuration before sending an RS. For sending periodic router
advertisements in 802.16 Networks, BS needs to send the RA with
separate IP prefix in unicast manner for each SS explicitly.
Jee, Editor, et al. Expires August 19, 2007 [Page 9]
Internet-Draft IP over 802.16 PS and Goals February 2007
- Prefix Assignment:
Separate IP prefix should be distributed for each SS to locate them
on different IP Subnets. When a SS moves between BSs under the same
AR, the AR needs to redistribute the same IP Subnet prefix which the
SS used at the previous BS.
- Next-Hop:
SS's next-hop always needs to be the AR which provides the IP
connectivity at that access network.
- Neighbor Unreachability Detection (NUD):
Because SS always see an AR as the next hop, the NUD is required only
for that AR. Also the requirement of NUD may depend on the existence
of a connection to the BS for that particular destination. If there
exists multiple ARs (so the default routers), it is unknown if the
NUD is required if an AR is not serving any 802.16 MAC connection.
- Address Autoconfiguration:
Because a unique prefix is assigned to each SS, the IP Subnet
consists of only one SS and an AR. Therefore, duplicate address
detection (DAD) is trivial.
5.3. Ethernet like Link model for Ethernet CS: Problems
- Address Resolution:
For Ethernet CS, sender needs to perform an address resolution to
fill the destination Ethernet address field even though that address
is not used for transmitting an 802.16 frame on the air. That
Ethernet destination address is used for a BS or bridge to decide
where to forward that Ethernet frame after decapsulating the 802.16
frame. When the destination's IP address has the same address prefix
with its own, the sender should set the Ethernet frame's destination
address as the destination itself. To acquire that address, the
address resolution should be performed throughout conventional
broadcast and multicast based ARP or NDP. However, this multicast
and broadcast packets results in the problem of waking up the dormant
SSs.
- Router Discovery:
All SSs under the AR are located in the same broadcast domain in the
Ethernet like link model. In this environment, sending periodic
Router Advertisements with the destination of all-nodes multicast
Jee, Editor, et al. Expires August 19, 2007 [Page 10]
Internet-Draft IP over 802.16 PS and Goals February 2007
address results in the problem of waking up the dormant SSs.
- Prefix Assignment:
Because the same IP prefix is shared with multiple SSs, an IP Subnet
consists of multiple SSs and an AR. 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 is not possible only with Ethernet CS without adding
bridging functionality on top of BS or between BS and AR.
- Next-Hop:
When Ethernet CS is used and the accompanying Ethernet capability
emulation is implemented, the next-hop for the destination IP with
the same global prefix with the sender or link local address type
should be the destination itself not an AR.
- Neighbor Unreachability Detection (NUD):
All SSs under the same AR are all the neighbors. Therefore, the NUD
is required for all the SSs and AR.
- Address Autoconfiguration:
The duplicate address detection (DAD) should be performed among
multiple SSs and an AR which are using the same IP prefix. The
previous multicast based DAD cause the problem of waking up the
dormant SSs.
5.4. IP over IEEE 802.16 Goals
The following are the goals in no particular order that point at
relevant work to be done in IETF.
Goal #1. Define the way to provide the point-to-point link model for
IP CS.
Goal #2. Reduce the power consumption caused by waking up dormant
terminals for Ethernet like link model.
Goal #3. Do not cause multilink subnet problems.
Goal #4. Provide the applicability of the previous security works
like SEND [RFC3971].
Goal #5. Do not introduce any new security threats.
Jee, Editor, et al. Expires August 19, 2007 [Page 11]
Internet-Draft IP over 802.16 PS and Goals February 2007
6. IANA Considerations
This draft does not require any actions from IANA.
7. Security Considerations
This documents describes the problem statement and goals for IP over
802.16 networks and does not introduce any new security threats.
8. Acknowledgment
Special thanks to David Johnston and Phil Roberts for the amendment
and suggestion to improve the document during the WG last call.
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 preceding this work.
We also would like to express special thanks to the previous authors
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.
9. References
9.1. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
9.2. Informative References
[I-D.ietf-16ng-ipv6-link-model-analysis]
Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
based Networks",
Jee, Editor, et al. Expires August 19, 2007 [Page 12]
Internet-Draft IP over 802.16 PS and Goals February 2007
draft-ietf-16ng-ipv6-link-model-analysis-02 (work in
progress), January 2007.
[I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-10 (work in progress),
January 2007.
[I-D.thaler-intarea-multilink-subnet-issues]
Thaler, D., "Issues With Protocols Proposing Multilink
Subnets", draft-thaler-intarea-multilink-subnet-issues-00
(work in progress), March 2006.
[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 Std 802.16e, "IEEE standard for Local and
metropolitan area networks, Part 16:Air Interface for
fixed and Mobile broadband wireless access systems",
October 2005.
Authors' Addresses
Junghoon Jee
ETRI
Email: jhjee@etri.re.kr
Syam Madanapalli
LogicaCMG
Email: smadanapalli@gmail.com
Jeff Mandin
Runcom
Email: jeff@streetwaves-networks.com
Jee, Editor, et al. Expires August 19, 2007 [Page 13]
Internet-Draft IP over 802.16 PS and Goals February 2007
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 19, 2007 [Page 14]
Internet-Draft IP over 802.16 PS and Goals 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).
Jee, Editor, et al. Expires August 19, 2007 [Page 15]
