GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5154

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

  1. 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.
  1. 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

  1. 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.
  1. Next-Hop:
 SS's next-hop always needs to be the AR that provides the IP
 connectivity at that access network.
  1. 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.
  1. 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

  1. 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].
  1. 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].
  1. 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.
  1. 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.
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5154.txt · Last modified: 2008/04/07 23:05 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki