<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

        <!ENTITY rfc1661 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1661.xml'>
      
      <!ENTITY rfc3971 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>  
      
      <!ENTITY rfc4541 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4541.xml'>
                
      <!ENTITY rfc4903 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4903.xml'>
      
      <!ENTITY rfc4968 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4968.xml'>   
              
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc rfcedstyle="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>

<rfc number="5154" category="info">
	<front>
		<title abbrev="IP over 802.16 PS and Goals">IP over 802.16 Problem Statement and Goals</title>

		<author initials="J." surname="Jee" fullname="Junghoon Jee" role="editor">
			<organization abbrev="">ETRI</organization>
			<address>
			
			<postal>
				<street>161 Gajeong-dong Yuseong-gu</street>
					<city>Daejeon</city>
					<code>305-700</code>
				
				<country>Korea</country>
			</postal>			
			    <phone>+82 42 860 5126</phone> 
				<email>jhjee@etri.re.kr</email>
			</address>
		</author>

<!-- [Junghoon] I've updated my contact information. -->
		
		<author initials="S." surname="Madanapalli" fullname="Syam Madanapalli">
			<organization abbrev="">Ordyn Technologies</organization>
			<address>
			<postal>
     		              <street>1st Floor, Creator Building, ITPL</street>
			        <city>Bangalore - 560066</city> 
			        <country>India</country>
			</postal>			
			<email>smadanapalli@gmail.com</email>
			</address>
		</author>
		
		
<!-- [Gabriel] I've updated Jeff's info here and under "contributors". -->
		<author initials="J." surname="Mandin" fullname="Jeff Mandin">
			<organization abbrev="">Runcom</organization>
			<address>
				<email>j_mandin@yahoo.com</email>
 			</address>
		</author>
		
		<date month="March" year="2008"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html. 

Junghoon: Yes, I included related keywords.
-->

<keyword>WiMAX, Mobile WiMAX, WiBro</keyword>

		<abstract>
			<t>
			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.
			</t>
		</abstract>
	</front>
	
	<middle> 
		<section title="Introduction">
		<t>
		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 <xref target="IEEE802.16"/>. 
		</t>

		<t>
		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
		<xref target="IEEE802.16"/>. 
		</t>
   		
		<t>
		IEEE 802.16 <xref target="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.
        </t>
        
        <t>
       	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 <xref target="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.
        </t>
        <?rfc needLines="10" ?>
		<t>
 		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. 
		</t>
		
		</section>

		
		<section title="Terminology">
		
		<t>
   		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 <xref target="IEEE802.16e"/>.
   		</t>
   		
   		<t>
   		Base Station (BS): A generalized equipment set that provides 
		connectivity, management, and control between the subscriber 
		station and the IEEE 802.16 networks.
   		</t>  	
   		
   		<t>
		Access Router (AR): An entity that performs an IP routing function 
		to provide IP connectivity for the subscriber station (SS or MS).
  		</t>

   		<t>
   		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.</t>

		<t>
		Service Data Unit (SDU): This refers to the data format passed to
   		the upper edge of the MAC
		</t>
   
		<t>
		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 <xref target="RFC4903"/>.
		</t>
		
			
		<t>
		Link: Topological area bounded by routers, which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet 
		as specified from <xref target="RFC4903"/>. 
		</t>
		
		<t>
		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.
		</t>
		
		
<!-- [Junghoon] The following terminology of Dormant mode is not supposed to be included in the document. 
                This part should be deleted.     

    	<t>
    	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 IEEE 802.16 network.
		In the dormant mode, the mobile station is only listening at scheduled 
		intervals to the paging channel. The IEEE 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.
		</t>
-->
   			
    	
    	<t>
    	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.
    	</t>

		<t>
		Ethernet CS: The 802.3/Ethernet CS specific part of the Packet 
		CS defined in <xref target="IEEE802.16"/>.
		</t>

		<t>	
		802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS 
		defined in <xref target="IEEE802.16"/>.
		</t>
		
		<t>
		IP CS: The IP specific subpart of the Packet CS defined in <xref target="IEEE802.16"/>.
		</t>

		<t>
		IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 (Packet, IPv4)
		</t>
		
		<t>
		IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 (Packet, IPv6).
		</t>

		</section>
		
	     	
      	<section title="Overview of the IEEE 802.16 MAC Layer" anchor="overview">
		
		<t>
		IEEE 802.16 <xref target="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.
		
		</t>

			<section title="Transport Connections">
			<t>
			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.
			</t>
	
		    <t>
		    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).
		    </t>

		    <t>
		    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.
		    </t>
   		    </section>

		   <section title="IEEE 802.16 PDU Format">

		   <t>
		   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.
			</t>
			
		   <t>
		   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.
           </t>
           </section>
           
           <section	title="IEEE 802.16 Convergence Sublayer">
           
           <t>
           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.
           </t>
           
           <t>
           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.
		   </t>
		   
<t><list style="symbols">
		   <t>
		   "The IP Specific Subpart" carries IP packets over a point-to-point connection.
		   </t>
		   
		   <t>
		   "The 802.3 Ethernet Specific Subpart" carries packets encoded in the 802.3/Ethernet packet format
		   with 802.3 style headers.		   
		   </t>
		   
		   <t>
		   "The 802.1Q VLAN Specific Subpart" carries 802 style packets that contain 802.1Q VLAN Tags.
		   </t>
</list></t>
		   
		   <t>
		   Classifiers applied to connections at the time of connection establishment further classify and 
		   subdivide the nature of the traffic over a connection.
		   </t>
		   
		   <t>
		   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.		   
		   </t>
		   
		   <t>
		   The classifications that apply to the 802.1Q/VLAN CS include IPv4 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN.		   
		   </t>
		   
		   <t>
		   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.
		   </t>
		   
		   <t>
		   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.
		   </t>
		   
		   <t>
		   For the sake of brevity in this document, the following naming conventions will be used for
		   particular classifications of particular subparts of particular CSs.		   
		   </t>
		   
<t><list style="symbols">
		   <t>
		   IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, IPv4)		   
		   </t>
		   
		   <t>
		   IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, IPv6)
		   </t>
		   
		   <t>
		   Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 (Packet, 802.3/Ethernet)
		   </t>
		   
</list></t>

		   <t>
		   An implementation of IEEE 802.16 can support multiple CS types.
		   </t>
		   
		   <t>
		   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.
		   </t>
		   </section>

     	</section>
      	
     <section title="IP over IEEE 802.16 Problem Statement and Goals">
     
     <section title="Root Problem">
     
     <t>
     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 that uses the same IP address prefix where that prefix is not further
     subdivided except into individual addresses. <xref target="RFC4903"/>
     There are three different IP Subnet models <xref target="RFC4968"/> that are possible for IEEE 802.16 network:
     </t>
     
     <t>
     1) Point-to-point Link Model
     </t>	
     
     <t>
     2) Ethernet-like Link Model     
     </t>
     
     
     <t>
     3) Shared IPv6 Prefix Link Model
     </t>
     
     <t>
     The specific problems and issues when adopting the above IP Subnet models to the IEEE 802.16 network are as below:
     </t>
     
     <t>
     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 <xref target="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.

     </t>
          
     <t>
     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 <xref target="IEEE802.16e"/>.       
     </t>
     
<!-- [rfced] Please confirm that the sentence above is correct. 
  The IESG's "Note to the RFC Editor" was not exactly followed
  because it made the sentence unreadable:

ORIGINAL
   Moreover, frequent IP multicast and broadcast
   signaling should be avoided not to wake up sleep/idle [IEEE802.16e]
   SSs.

Note to RFC Editor:
  In Section 4.1, please change "not to wake up sleep/idle
  [IEEE802.16e] SSs" to "SSs which are in the sleep/idle mode
  [IEEE802.16e]".

YIELDS
   Moreover, frequent IP multicast and broadcast
   signaling should be avoided SSs which are in the sleep/idle mode 
   [IEEE802.16e].
   
CONFIRMATION by Junghoon:
   Yes, the suggested sententence is correct. Thank you!
-->

     
     <t>
     The shared IPv6 prefix link model eventually results in  multi-link subnet problems <xref target="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 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.
     </t>     
         
     	<t>
     	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.
     	</t>
     	
     	<t>
     	1. Point-to-Point Link model for IP CS.
     	</t>
     	
     	<t>
     	2. Ethernet-like Link Model for Ethernet CS.
     	</t>
     	
     	<t>
     	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.
     	</t>
     	
        </section>	
     	
     	<section title="Point-to-Point Link Model for IP CS: Problems">
 
      	<t>
      	- Address Resolution: 
       	</t>
      	
      	<t>
         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. 
  		 
 <!-- [Junghoon] The IP CS represents the IP Specific Subpart as sepecified in the Section 1 and 2. 
 
 PREVIOUS: In the case of Internet Protocol Communications Security (IPCS),
 
 CORRECTION: In the case of IP CS, 
 
 What's done by Junghoon: I applied the correction. 
-->        		 

  		 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.
      	</t>
      	
      	<t>
      	- Router Discovery:
		</t>
		
		<t>
		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.
		</t>
<!-- [rfced] Please expand RA in the sentence above. Is it Router Advertisement? 

Feedback by Junghoon:
   Yes, it's Router Advertisement. I did expand.   
-->


		<t>
  		- Prefix Assignment:
		</t>
		
		<t>
   		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.
		</t>
<?rfc needLines="10" ?>
		<t>
   		- Next-Hop:
   		</t>
   		
   		<t>
		SS's next-hop always needs to be the AR that provides the IP connectivity at that access network.
		</t>

		<t>
  		- Neighbor Unreachability Detection (NUD):
  		</t>
  		
  		<t>
	    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. 
		</t>

		<t>
  		- Address Autoconfiguration:
  		</t>
  		
  		<t>
		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. 
       	</t>
      	
      	</section>
      	
      	<section title="Ethernet-Like Link Model for Ethernet CS: Problems">
      	
   		<t>
   		- Address Resolution:
   		</t>
   		
   		<t>
   		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.,
   		<xref target="RFC4541"/>), these multicast and
   		broadcast packets result in the problem of waking up the
   		SSs that are in sleep/idle mode <xref target="IEEE802.16e"/>.
   		</t>   	
  

		<t>
		- Router Discovery:
		</t>
		
		<t>
		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 SSs that are in sleep/idle mode <xref target="IEEE802.16e"/>.
		</t>

 		<t>
    	- Prefix Assignment:
    	</t>
    	
    	<t>
    	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 
<?rfc needLines="10" ?>
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.
		</t>
   
<!-- [rfced] Please clarify the sentence above.  

SUGGESTED: 
However, direct communication using link-layer address between two SSs
is not possible with Ethernet CS unless bridging functionality is
added on top of the BS or between the BS and AR.

OR

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.

Feedback by Junghoon:
   Yes, the second suggestion is the better. I applied the second suggestion into the document. 
-->



		<t>
		- Next-Hop:
		</t>
		
		<t>
    	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.
		</t>
	
		<t>
		- Neighbor Unreachability Detection (NUD):
		</t>
		
		<t>
		All SSs under the same AR are all the neighbors. Therefore, the NUD is required for all the SSs and AR. 
		</t>
	
		<t>
		- Address Autoconfiguration:
		</t>
		
		<t>
   		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 <xref target="IEEE802.16e"/>.	
		</t>
  
      	</section>
      	

<!-- [Junghoon] The following section 4.4 and 4.5 are not supposed to be included in the document. 
                Those section titles should be deleted.
                
                      
      	<section title="Problems from the Coexistence of Multiple Convergence Sublayers">
      	
      	</section>
      	
      	<section title="Problems from IPv4 and IPv6 Interleaved over IP CS">
      	   	
      	</section>
-->

      	
   
      	
 		<section title="IP over IEEE 802.16 Goals">
 		
 		<t>
   		The following are the goals in no particular order that point at
   		relevant work to be done in IETF.
   		</t>

<t><list style="hanging" hangIndent="10">
		<t hangText="Goal #1.">Define the way to provide the point-to-point link model for IP CS. 
	   </t>
 	   
 	   <t hangText="Goal #2.">Reduce the power consumption caused
 	   by waking up sleep/idle <xref target="IEEE802.16e"/> terminals for Ethernet-like link model.
 	   </t>
    
 
 	   <t hangText="Goal #3.">Avoid multi-link subnet problems.
 	   </t>
 
 	   <t hangText="Goal #4.">Allow applicability of security
	     schemes such as SEcure Neighbor Discovery (SEND) <xref target="RFC3971"/>.
 	   </t>
 	   
 	   <t hangText="Goal #5.">Do not introduce any new security threats.
 	   </t>

	   <t hangText="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.
 	   </t>
</list></t>

  	    </section>
     </section>	
      	
  		<section title="Security Considerations">
		<t>
		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 <xref target="IEEE802.16"/><xref target="IEEE802.16e"/>.
		</t>
		</section>
 
 
 		<section title="Contributors">
		<t> 
		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. 
		</t>
		
		<t>The problem statement team members can be reached at: </t>

<t><list>		
		<t>
		Junghoon Jee, jhjee@etri.re.kr
		</t>

		<t>
	    Syam Madanapalli, smadanapalli@gmail.com
	    </t>

		<t>
		Jeff Mandin, j_mandin@yahoo.com
		</t> 
   
   		<t>
   		Gabriel Montenegro, g_e_montenegro@yahoo.com
   		</t>   
   
   		<t>
   		Soohong Daniel Park, soohong.park@samsung.com
   		</t>

   		<t>
		Maximilian Riegel, maximilian.riegel@nsn.com 
		</t>
</list></t>
		
		</section>
 
  		<section title="Acknowledgments">
 		
			<t>The authors would like to express special
				thank to David Johnston for his help
				with <xref target="overview"/>,
				"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.
			</t>

			<t>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.
   			</t>

   		</section>

</middle>

	
	<back>
		<references title="Normative References">		
			&rfc1661;
			&rfc3971;		
		</references>
		<references title="Informative References">	
			&rfc4541;	
			&rfc4903;
			&rfc4968;				
            <reference anchor="IEEE802.16">
			    <front>
					<title>IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems</title>
	
           	<author>

               	 	<organization>IEEE Std 802.16-2004</organization>
	 	         	</author>
	
       	     <date month="October" year="2004" />
	   		     </front>

    		</reference>
    		
    		<reference anchor="IEEE802.16e">
			    <front>
					<title>IEEE standard for Local and metropolitan area
        networks, Part 16:Air Interface for fixed and Mobile broadband
        wireless access systems</title>
	
           	<author>

               	 	<organization>IEEE Std 802.16e</organization>
	 	         	</author>
	
       	     <date month="October" year="2005" />
	   		     </front>

    		</reference>
   		
  		</references>  	  		
	</back>
</rfc>
