diff options
Diffstat (limited to 'doc/rfc/rfc5154.txt')
| -rw-r--r-- | doc/rfc/rfc5154.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc5154.txt b/doc/rfc/rfc5154.txt new file mode 100644 index 0000000..e53b7a7 --- /dev/null +++ b/doc/rfc/rfc5154.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group J. Jee, Ed. +Request for Comments: 5154 ETRI +Category: Informational S. Madanapalli + Ordyn Technologies + J. Mandin + Runcom + April 2008 + + + IP over IEEE 802.16 Problem Statement and Goals + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This document specifies problems in running IP over IEEE 802.16 + networks by identifying specific gaps in the IEEE 802.16 Media Access + Control (MAC) for IPv4 and IPv6 support. This document also provides + an overview of IEEE 802.16 network characteristics and convergence + sublayers. Common terminology used for the base guideline while + defining the solution framework is also presented. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Overview of the IEEE 802.16 MAC Layer . . . . . . . . . . . . 4 + 3.1. Transport Connections . . . . . . . . . . . . . . . . . . 4 + 3.2. IEEE 802.16 PDU Format . . . . . . . . . . . . . . . . . . 5 + 3.3. IEEE 802.16 Convergence Sublayer . . . . . . . . . . . . . 5 + 4. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 6 + 4.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Point-to-Point Link Model for IP CS: Problems . . . . . . 8 + 4.3. Ethernet-Like Link Model for Ethernet CS: Problems . . . . 9 + 4.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 + + + + + + +Jee, et al. Informational [Page 1] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + +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]. + + IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at + the MAC, physically arranged in a point-to-multipoint structure with + the Base Station (BS) terminating one end of each connection and an + individual Subscriber Station (SS) terminating the other end of each + connection. The IEEE 802.16 convergence sublayer (CS) is at the + uppermost part of the MAC that is responsible for assigning transmit- + direction Service Data Units (originating from a higher layer + application, e.g., IP or Ethernet at the BS or SS) to a specific + outbound transport connection. IEEE 802.16 defines two convergence + sublayer types, the ATM Convergence Sublayer (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 scope of + IETF efforts. + + There is 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. An 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 in + [RFC4903]. 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 capabilities: IP routing functionality + in the case of IP CS and bridging functionality in the case of + Ethernet CS. This means that the link-layer's characteristics + beneath IP can change according to the adopted convergence sublayers. + + + + + +Jee, et al. Informational [Page 2] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + This document provides the feasible IP Subnet model for each IP CS + and Ethernet CS and specifies the problems in running IP for each + case. This document also presents an overview of IEEE 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. Terminology + + Subscriber Station (SS): An end-user equipment that provides + connectivity to the IEEE 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 set that provides + connectivity, management, and control between the subscriber station + and the IEEE 802.16 networks. + + Access Router (AR): An entity that performs an IP routing function to + provide IP connectivity for the subscriber station (SS or MS). + + Protocol Data Unit (PDU): This refers to the data format passed from + the lower edge of the MAC to the PHY, which typically contains SDU + data after fragmentation/packing, encryption, etc. + + Service Data Unit (SDU): This refers to the data format passed to the + upper edge of the 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 [RFC4903]. + + Link: Topological area bounded by routers, which decrement the IPv4 + TTL or IPv6 Hop Limit when forwarding the packet as specified from + [RFC4903]. + + Transport Connection: The MAC layer connection in IEEE 802.16 between + an SS (MS) and BS with a specific Quality of Service (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 connection intended for user + traffic. The scope of the transport connection is between the SS + (MS) and the BS. + + Connection Identifier (CID): A 16-bit value that identifies a + connection to equivalent peers in the IEEE 802.16 MAC of the SS (MS) + and BS. + + + +Jee, et al. Informational [Page 3] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS + defined in [IEEE802.16]. + + 802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined + in [IEEE802.16]. + + IP CS: The IP specific subpart of the Packet CS defined in + [IEEE802.16]. + + IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 + (Packet, IPv4) + + IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 + (Packet, IPv6). + +3. Overview of the IEEE 802.16 MAC Layer + + IEEE 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 SS in the network + possesses a 48-bit MAC address. The BS possesses a 48-bit unique + identifier called "BSId". The BS and SS learn each others' MAC + Address/BSId during the SS's entry into the network. Additionally, + the BS may possess a 48-bit MAC address, but this is only known to + the SS if using the Ethernet CS. + +3.1. Transport Connections + + User data traffic in both the BS-bound (uplink) and SS-bound + (downlink) 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 an SS to the IEEE 802.16 network, no data + traffic is possible as there are no transport connections between the + BS and the SS yet. 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. + + + + + + + +Jee, et al. Informational [Page 4] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + +3.2. IEEE 802.16 PDU Format + + An IEEE 802.16 PDU (i.e., the format that is transmitted over the + airlink) consists of a Generic MAC header, various optional + subheaders, and a data payload. + + The IEEE 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 IEEE 802.16 MAC header. + +3.3. IEEE 802.16 Convergence Sublayer + + The IEEE 802.16 convergence sublayer (CS) is the component of the MAC + that is responsible for mapping between the MAC service and the + internal connection oriented service of the MAC CPS (Common Part + Sublayer), through classification and encapsulation. The + classification process assigns transmit-direction Service Data Units + (originating from a higher layer application, e.g., 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 + (e.g., the destination MAC address in an Ethernet frame, or the Type + of Service (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 Service Data Unit, + the convergence sublayer proceeds from the first entry of the + classifier table to the last, and evaluates the fields of the Service + Data Unit for a match with the table entry's classifier. When a + match is found, the convergence sublayer associates the Service Data + Unit with the target CID (for eventual transmission), and the + remainder of the IEEE 802.16 MAC and PHY processing can take place. + + IEEE 802.16 defines two convergence sublayer types, the ATM CS and + the Packet CS. The ATM CS supports 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. + + 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. + + + + +Jee, et al. Informational [Page 5] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + Classifiers applied to connections at the time of connection + establishment further classify and subdivide 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 RObust Header Compression + (ROHC) header compression and 802.3/Ethernet with Enhanced Compressed + Real-Time Protocol (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 IEEE 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 IEEE 802.16 can support multiple CS types. + + We can observe that the CS type, subpart, and classification actually + defines the type of data interface (e.g., IPv4/IPv6 or 802.3) that is + presented by IEEE 802.16 to the higher layer application. + +4. IP over IEEE 802.16 Problem Statement and Goals + +4.1. Root Problem + + The key issue when deploying IP over IEEE 802.16 networks is how to + configure an IP Subnet over that link, which is connection-oriented + and point-to-point in the MAC level. IP Subnet is a topological area + + + +Jee, et al. Informational [Page 6] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + that uses the same IP address prefix where that prefix is not further + subdivided except into individual addresses. [RFC4903] There are + three different IP Subnet models [RFC4968] that are possible for IEEE + 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 as below: + + In the point-to-point link model, each SS under a BS resides on a + different IP Subnet. 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. 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 IEEE 802.16 network because IEEE 802.16 does not define a + convergence sublayer, which can encapsulate and decapsulate PPP + frames. Therefore, there needs to be a mechanism to provide a point- + to-point link between an SS and an AR in case of IP CS. The other + alternative is to utilize 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 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 + IEEE 802.16's Ethernet CS to configure this link model. However, + IEEE 802.16's MAC feature is still connection-oriented, and does not + provide multicast and broadcast connection for IP packet transfer. + Therefore, we need a mechanism like IEEE 802.1D to realize multicast + and broadcast. Moreover, frequent IP multicast and broadcast + signaling should be avoided so as not to wake up the SSs that are in + sleep/idle mode [IEEE802.16e]. + + The shared IPv6 prefix link model eventually results in multi-link + subnet problems [RFC4903]. In IEEE 802.16, the BS assigns separate + IEEE 802.16 connections for SSs. Therefore, SSs are placed on + different links. In this situation, distributing shared IPv6 prefix + for SSs, which are placed on different links causes multi-link subnet + + + + + +Jee, et al. Informational [Page 7] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + problems. This applies to IP CS and even to Ethernet CS if no + bridging functionality is implemented on top of the BS or between the + BS and the 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 scope of + ongoing IETF work. Following 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 the IEEE 802.16 MAC, the + Point-to-Point link model is the feasible IP Subnet model in the case + of IP CS. 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. + +4.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 the case of IP CS, the IEEE + 802.16 MAC address is not used as part of the IEEE 802.16 frame so + typical usage of the Address Resolution Protocol (ARP) or Neighbor + cache does not apply. Thus, performing the address resolution may be + redundant in the case of IP CS. For IPv4, ARP cannot be carried by + the IP CS, so is not used either by the SS or by the BS. For IPv6, + address resolution is the function of IP layer, and IP reachability + state is maintained through neighbor discovery packets. Therefore, + blocking neighbor discovery packets would break the neighbor + unreachability detection model. + + - Router Discovery: + + The BS needs to send the Router Advertisement (RA) with separate IP + prefix in unicast manner for each SS explicitly to send periodic + router advertisements in IEEE 802.16 Networks. + + + + + + + + +Jee, et al. Informational [Page 8] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + - Prefix Assignment: + + Separate IP prefix should be distributed for each SS to locate them + on different IP Subnets. When an 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 that provides the IP + connectivity at that access network. + + - Neighbor Unreachability Detection (NUD): + + Because the SS always sees 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. + + - 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. + +4.3. Ethernet-Like Link Model for Ethernet CS: Problems + + - Address Resolution: + + For Ethernet CS, the sender needs to perform an address resolution to + fill the destination Ethernet address field even though that address + is not used for transmitting an IEEE 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 IEEE + 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 Neighbor Discovery + Protocol (NDP). However, if not filtered (e.g., [RFC4541]), these + multicast and broadcast packets result in the problem of waking up + the SSs that are in sleep/idle mode [IEEE802.16e]. + + - 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, et al. Informational [Page 9] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + address results in the problem of waking up the SSs that are in + sleep/idle mode [IEEE802.16e]. + + - Prefix Assignment: + + Because the same IP prefix is shared with multiple SSs, an IP Subnet + consists of multiple SSs and an AR. The 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 with Ethernet CS alone; bridging + functionality must be added on top of the BS or between the 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: + + Duplicate Address Detection (DAD) should be performed among multiple + SSs and an AR, which use the same IP prefix. The previous multicast- + based DAD causes the problem of waking up the SSs that are in sleep/ + idle mode [IEEE802.16e]. + +4.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 sleep/idle + [IEEE802.16e] terminals for Ethernet-like link model. + + Goal #3. Avoid multi-link subnet problems. + + Goal #4. Allow applicability of security schemes such as SEcure + Neighbor Discovery (SEND) [RFC3971]. + + + + +Jee, et al. Informational [Page 10] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + + Goal #5. Do not introduce any new security threats. + + Goal #6. Review management requirements and specifically the + interfaces and specific management model (objects) for IP + over IEEE 802.16 in collaboration with IEEE 802.16 working + group. + +5. Security Considerations + + This documents describes the problem statement and goals for IP over + IEEE 802.16 networks and does not introduce any new security threats. + The IEEE 802.16 link-layer employs cryptographic security mechanisms + as specified in [IEEE802.16][IEEE802.16e]. + +6. Contributors + + This document is a joint effort of the problem statement team of the + IETF 16ng Working Group. The team members include Junghoon Jee, Syam + Madanapalli, Jeff Mandin, Gabriel Montenegro, Soohong Daniel Park, + and Maximilian Riegel. + + The problem statement team members can be reached at: + + Junghoon Jee, jhjee@etri.re.kr + + Syam Madanapalli, smadanapalli@gmail.com + + Jeff Mandin, j_mandin@yahoo.com + + Gabriel Montenegro, g_e_montenegro@yahoo.com + + Soohong Daniel Park, soohong.park@samsung.com + + Maximilian Riegel, maximilian.riegel@nsn.com + +7. Acknowledgments + + The authors would like to express special thank to David Johnston for + his help with Section 3, "Overview of the IEEE 802.16 MAC Layer", and + for carefully reviewing the entire document, and also to Phil Roberts + for suggesting the reorganization of the document depending on the + baseline IP subnet models. + + The authors also would like to thank Jari Arkko, HeeYoung Jung, + Myung-Ki Shin, Eun-Kyoung Paik, Jaesun Cha, and the KWISF (Korea + Wireless Internet Standardization Forum) for their comments and + contributions. + + + + +Jee, et al. Informational [Page 11] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + +8. References + +8.1. Normative References + + [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, July 1994. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + March 2005. + +8.2. Informative References + + [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. + + [RFC4541] Christensen, M., Kimball, K., and F. Solensky, + "Considerations for Internet Group Management Protocol + (IGMP) and Multicast Listener Discovery (MLD) Snooping + Switches", RFC 4541, May 2006. + + [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, + June 2007. + + [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for + 802.16 Based Networks", RFC 4968, August 2007. + + + + + + + + + + + + + + + + + + +Jee, et al. Informational [Page 12] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + +Authors' Addresses + + Junghoon Jee (editor) + ETRI + 161 Gajeong-dong Yuseong-gu + Daejeon 305-700 + Korea + + Phone: +82 42 860 5126 + EMail: jhjee@etri.re.kr + + + Syam Madanapalli + Ordyn Technologies + 1st Floor, Creator Building, ITPL + Bangalore - 560066 + India + + EMail: smadanapalli@gmail.com + + + Jeff Mandin + Runcom + + EMail: j_mandin@yahoo.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Jee, et al. Informational [Page 13] + +RFC 5154 IP over 802.16 PS and Goals April 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Jee, et al. Informational [Page 14] + |