IP over IEEE 802.16 Problem Statement and Goals
draft-ietf-16ng-ps-goals-04

Network Working Group                                     J. Jee, Editor
Internet-Draft                                                      ETRI
Intended status: Informational                            S. Madanapalli
Expires: June 21, 2008                                Ordyn Technologies
                                                               J. Mandin
                                                                  Runcom
                                                       December 19, 2007

               IP over 802.16 Problem Statement and Goals
                    draft-ietf-16ng-ps-goals-04.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 June 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies problems in running the IETF IP protocols
   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.  Common terminology used for the base guideline while

Jee, Editor, et al.       Expires June 21, 2008                 [Page 1]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   defining the solution framework is also presented.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of the IEEE 802.16 MAC layer  . . . . . . . . . . . .  5
     3.1.  Transport Connections  . . . . . . . . . . . . . . . . . .  5
     3.2.  802.16 PDU format  . . . . . . . . . . . . . . . . . . . .  5
     3.3.  802.16 Convergence Sublayer  . . . . . . . . . . . . . . .  6
   4.  IP over IEEE 802.16 Problem Statement and Goals  . . . . . . .  7
     4.1.  Root Problem . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Point-to-Point Link model for IP CS: Problems  . . . . . .  9
     4.3.  Ethernet-like Link model for Ethernet CS: Problems . . . . 10
     4.4.  IP over IEEE 802.16 Goals  . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

Jee, Editor, et al.       Expires June 21, 2008                 [Page 2]
Internet-Draft         IP over 802.16 PS and Goals         December 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 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. 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 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.

   This document provides the feasible IP Subnet model for each IP CS
   and Ethernet CS and specifies the problems in running IP protocols
   for each case.  This document also presents an overview of 802.16

Jee, Editor, et al.       Expires June 21, 2008                 [Page 3]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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 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 that provides
   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 the 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 Service Data Unit 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 [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 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
   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 802.16 MAC of the SS (MS) and
   BS.

   Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS
   defined in [IEEE802.16].

Jee, Editor, et al.       Expires June 21, 2008                 [Page 4]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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

   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 a SS to the 802.16 network, no data traffic
   is possible as there are yet no transport connections between the BS
   and the 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.

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

Jee, Editor, et al.       Expires June 21, 2008                 [Page 5]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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.

3.3.  802.16 Convergence Sublayer

   The 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
   (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 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 802.16 MAC
   and PHY processing can take place.

   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.

   Classifiers applied to connections at the time of connection
   establishment further classifie 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

Jee, Editor, et al.       Expires June 21, 2008                 [Page 6]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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.

4.  IP over IEEE 802.16 Problem Statement and Goals

4.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 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.  [RFC4903] There are
   three different IP Subnet models [RFC4968] that are possible for
   802.16 network:

   1) Point-to-point Link Model

Jee, Editor, et al.       Expires June 21, 2008                 [Page 7]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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 802.16 network because 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 a 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
   802.16's Ethernet CS to configure this link model.  However, 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 not to wake up sleep/idle [IEEE802.16e]
   SSs.

   The shared IPv6 prefix link model eventually results in multi-link
   subnet problems [RFC4903].  In 802.16, the BS assigns separate 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 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
   16ng.  Following are the feasible IP Subnet models for each
   convergence sublayer used.

Jee, Editor, et al.       Expires June 21, 2008                 [Page 8]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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 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 IPCS, the 802.16
   MAC address is not used as part of the 802.16 frame so typical usage
   of the 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 RA with separate IP prefix in unicast manner
   for each SS explicitly to send periodic router advertisements in
   802.16 Networks.

   - 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 the SS always sees an AR as the next hop, the NUD is required

Jee, Editor, et al.       Expires June 21, 2008                 [Page 9]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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 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, if not filtered
   (e.g., [RFC4541]), these multicast and broadcast packets result in
   the problem of waking up the sleep/idle [IEEE802.16e] 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
   address results in the problem of waking up the sleep/idle
   [IEEE802.16e] SSs.

   - 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 only with Ethernet CS without adding
   bridging functionality 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

Jee, Editor, et al.       Expires June 21, 2008                [Page 10]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

   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 are using the same IP prefix.  The previous
   multicast-based DAD causes the problem of waking up the sleep/idle
   [IEEE802.16e] SSs.

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 multilink subnet problems.

   Goal #4.  Allow applicability of security schemes such as SeND
   [RFC3971].

   Goal #5.  Do not introduce any new security threats.

5.  IANA Considerations

   This document does not require any actions from IANA.

6.  Security Considerations

   This documents describes the problem statement and goals for IP over
   802.16 networks and does not introduce any new security threats.  The
   802.16 link-layer employs cryptographic security mechanisms as
   specified in [IEEE802.16][IEEE802.16e].

Jee, Editor, et al.       Expires June 21, 2008                [Page 11]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

7.  Contributors

   This document is a joint effort of the problem statement team of the
   16ng WG.  The team members include Junghoon Jee, Syam Madanapalli,
   Jeff Mandin, Gabriel Montenegro, Soohong Daniel Park and Maximilian
   Riegel.

   The problem statment team members can be reached at:

   Junghoon Jee, jhjee@etri.re.kr

   Syam Madanapalli, smadanapalli@gmail.com

   Jeff Mandin, jeff@streetwaves-networks.com

   Gabriel Montenegro, g_e_montenegro@yahoo.com

   Soohong Daniel Park, soohong.park@samsung.com

   Maximilian Riegel, maximilian.riegel@nsn.com

8.  Acknowledgment

   The authors would like to express special thank to David Johnston for
   his help with section 4, "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 KWISF (Korea Wireless
   Internet Standardization Forum) for their comments and contributions.

9.  References

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

Jee, Editor, et al.       Expires June 21, 2008                [Page 12]
Internet-Draft         IP over 802.16 PS and Goals         December 2007

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

Authors' Addresses

   Junghoon Jee
   ETRI
   161 Gajeong-dong Yuseong-gu
   Daejeon  305-350
   Korea

   Email: jhjee@etri.re.kr

   Syam Madanapalli
   Ordyn Technologies

   Email: smadanapalli@gmail.com

   Jeff Mandin
   Runcom

   Email: jeff@streetwaves-networks.com

Jee, Editor, et al.       Expires June 21, 2008                [Page 13]
Internet-Draft         IP over 802.16 PS and Goals         December 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 June 21, 2008                [Page 14]