16ng Working Group Sang-Eon. Kim Internet-Draft Joo Young. Yoon Expires: May 8, 2008 KT November 5, 2007 IP Transmission over IEEE 802.16 Networks draft-sekim-16ng-ip-00 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 May 8, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This draft describes IP packet transmission over IEEE 802.16 network to access Internet with PMP mode based IP CS. IP CS is a payload of IPv4 packet and IPv6 packet over IEEE 802.16 frame. This draft introduces host based packet delivery mechanism that can be classified layer 2 forwarding and IP tunnel based on public service and trial on IEEE 802.16 network. It describes HBPD on IEEE 802.16, requirements of the network elements and how to control IP CS on the IEEE 802.16. Kim & Yoon Expires May 8, 2008 [Page 1] Internet-Draft IP Transmission over IEEE 802.16 November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Review of an IEEE 802.3 based IP Network . . . . . . . . . . . 4 4. IEEE 802.16 based IP Network . . . . . . . . . . . . . . . . . 5 4.1. Requirements for HBPD in IEEE 802.16 Networks . . . . . . 6 4.2. HBPD with L2 forwarding in IEEE 802.16 Networks . . . . . 7 4.2.1. Uplink HBPD from MS to ACR . . . . . . . . . . . . . . 8 4.2.2. Downlink HBPD from ACR to MS . . . . . . . . . . . . . 8 4.3. HBPD with IP tunnel in IEEE 802.16 Networks . . . . . . . 9 4.3.1. Uplink HBPD from MS to ACR . . . . . . . . . . . . . . 9 4.3.2. Downlink HBPD from ACR to MS . . . . . . . . . . . . . 9 4.4. Consideration for L2 forwarding compared with IP tunnel . 9 5. Requirement of MS and operation . . . . . . . . . . . . . . . 10 5.1. Legacy IP device to compatible IEEE 802.16 . . . . . . . . 10 5.2. Dedicated IP device for IEEE 802.16 . . . . . . . . . . . 10 6. Network entry procedures of IEEE 802.16 Network . . . . . . . 10 6.1. IEEE 802.16 frame format . . . . . . . . . . . . . . . . . 10 6.2. Network entry procedures of IEEE 802.16 . . . . . . . . . 11 6.3. Network entry for IPv4 CS . . . . . . . . . . . . . . . . 13 6.4. Network entry for IPv6 CS . . . . . . . . . . . . . . . . 15 6.5. Network entry for IPv4 and IPv6 dual CS . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Kim & Yoon Expires May 8, 2008 [Page 2] Internet-Draft IP Transmission over IEEE 802.16 November 2007 1. Introduction The ITU Radiocommunication Assembly has granted approval of an update to Recommendation ITU-R M.1457 that includes a new radio interface "IMT-2000 OFDMA TDD WMAN" which is based on IEEE 802.16 standard. The [IEEE802.16] standards specify two modes for sharing wireless media. One is point-to-multipoint(PMP) and the other is mesh. It has started public service based on PMP modes with one of the IEEE 802.16 profiles. In PMP mode, uplink supports only unicast while downlink supports both unicast and multicast. The [IEEE802.16] standards specify service specific convergence sublayer (CS) to process higher-layer protocol data unit based on classification. The types of service specific CSs are asynchronous transfer mode (ATM) and packets such as IPv6, IPv4, IEEE 802.3/ Ethernet, IEEE 802.1Q VLAN, IPv6 over IEEE 802.3/Ethernet, IPv6 over IEEE 802.1Q VLAN, IPv4 over IEEE 802.3/Ethernet, IPv4 over IEEE 802.1Q VLAN and so on. This document describes IEEE 802.16 based Internet access with PMP mode based IP CS. IPv4 CS is IPv4 packet [RFC0791] and IPv6 CS is IPv6 packet [RFC2460] in the frame payload of IEEE 802.16 respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 'RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Terminology o Access Control Router (ACR):A generalized equipment sets providing connectivity, management, and control between the mobile station (MS) and Internet. It is defined by TTA for the first hop router for MS. o Access Service Network Gateway (ASNG):A generalized equipment sets providing connectivity and management between the mobile station (MS) and Internet. It is defined by WiMAX Forum. o Base Station (BS):A generalized equipment sets providing connectivity, management, and control between the MS and the ACR. o Connection Identifier(CID): A 16 bit value that identifies a connection between MS and BS. Kim & Yoon Expires May 8, 2008 [Page 3] Internet-Draft IP Transmission over IEEE 802.16 November 2007 o Convergence Sublayer (CS): Sublayer in the IEEE 802.16 MAC layer that classifies higher layer data and associates them to the proper MAC service flow identifier and connection identifier. o Host Based Packet Delivery (HBPD): A generalized function of packet delivery at the access network such as local area network. o IEEE 802.16: IEEE802.16 standards including IEEE802.16e standards. o Internet Protocol (IP): A network layer protocol both IPv4 [RFC0791] and IPv6 [RFC2460]. o Internet Protocol version 4 for Convergence Sublayer (IPv4 CS): IPv4 packet as a IEEE 802.16 payload that SHOULD set the bit #1 for type 7 in REG-REQ and REG-RSP message. The BS SHOULD set the value 1 for type 28 in DSx-REQ message to deliver IPv4 packet between MS and BS during the network entry procedure. The DSx stands for dynamic service addition, change, deletion. The MS SHOULD include the same TLV by DSx-RSP message. A BS and MS SHOULD maintain one service flow for IPv4 classification rules at least. o Internet Protocol version 6 for Convergence Sublayer (IPv6 CS): IPv6 packet as a IEEE 802.16 payload that SHOULD set the bit #2 for type 7 in REG-REQ and REG-RSP message. The BS SHOULD set the value 2 for type 28 in DSx-REQ message to deliver IPv6 packet during the network entry procedures. The MS SHOULD include the same TLV by DSx-RSP message. A BS and MS SHOULD maintain two service flow for IPv6 classification rules at least. 3. Review of an IEEE 802.3 based IP Network This section briefly reviews IEEE 802.3 based IP network to consider network architecture and packet delivery mechanism. |<----- IEEE 802.3 network ----->|<------ Internet ------->| wired connection |--+-------+----------+-------+--| /-------\ | | | | / \ +----+ +-+--+ +-+--+ +-+--+ +-+--+ +--+ Internet +--+ CH | | T1 | | T2 | ... | Tn | | ER +--+ \ / +----+ +----+ +----+ +----+ +----+ \-------/ Figure 1: Internet connection with Ethernet Kim & Yoon Expires May 8, 2008 [Page 4] Internet-Draft IP Transmission over IEEE 802.16 November 2007 Figure 1 depicts conceptual IP network with [IEEE802.3]. T is a terminal equipment that has an IEEE 802.3 network interface. T1 stands for terminal 1 and T2 stands for terminal 2 and Tn is n-th terminal. ER is an edge router that interconnects between IEEE 802.3 network and Internet. CH stands for correspondent host. An IEEE 802.3 network shares prefix information for IP routing to reduce routing information. The prefix length [RFC4632] set by network mask. It can be calculated when the n terminals are connected to the IEEE 802.3 network. Prefix Length = truncate ((log2 (n+2)) + 1) This prefix information SHOULD be same T1, T2, Tn and 802.3 interface of ER. An IP packet is forwarded from CH to ER based on prefix routing mechanism such as OSPF, IS-IS in the intra-AS, BGP for inter-AS in the Internet. This routing mechanism is named for 'prefix based routing (PBR)' in this document. When the CH communicates with T1, received packet from CH SHOULD forwarded to T1 at ER. ER performs ARP [RFC0826] for this purpose and maintain ARP cache table. This packet transmission mechanism from ER to T1 called 'L2 forwarding' in this document. L2 forwarding means that ER uses layer 2 frame to transmit layer 3 packet. This is a kinds of HBPD in the IEEE 802.3 network compared to PBR in the Internet. The IEEE 802.3 is an access network and Internet is a backbone network in the network architecture viewpoint. The access network is between end terminals and first hop router. ER is a first hop router in the IEEE 802.3 network. In general, access network SHOULD support HBPD considering other access network such as digital subscriber line (DSL), point to point protocol (PPP) and so on. The IEEE 802.16 network is one of the access network for Internet. The access network for Internet SHOULD support HBPD and Internet supports PBR. 4. IEEE 802.16 based IP Network Figure 2 depicts conceptual IP network with IEEE 802.16. MS is a mobile station that has an IEEE 802.16 network interface. BS stands for base station that supports IEEE 802.16 protocols. It controls MSs and manages radio resources with ACR. ACR stands for access control router that interconnect between IEEE 802.16 network and Internet. It SHOULD provide ER functions and SHOULD be support BS interface functions of radio resource management. Therefore, an ACR has additional functions compared with an ER. Kim & Yoon Expires May 8, 2008 [Page 5] Internet-Draft IP Transmission over IEEE 802.16 November 2007 The IEEE 802.16 network for fixed/nomadic deployment can use shared prefix that is similar to IEEE 802.3 network. In case of IEEE 802.16 network supports mobility function, it does not depend on the prefix shares or not. Because a packet forwarding mechanism for HBPD MAY use either L2 forwarding or IP based tunnel in the IEEE 802.16 network. |<----- PMP mode of | | | IEEE 802.16 network ----->|<----- Internet ----->| | | | +---------+ | BSn +--+ +---------+ | | ... | | +------+ /--------\ +---------+ +-+ ACR/ | / \ +----+ | BS1 +----+ ASNG +----+ Internet +--+ CH | +-+--+--+-+ +------+ \ / +----+ | | | \--------/ +-----+ | +--------+ | | | wireless connection +--+--+ +--+--+ +--+--+ | MS1 | | MS2 | ... | MSn | +-----+ +-----+ +-----+ Figure 2: Internet connection with IEEE 802.16 An MS SHOULD performs network entry procedures to connect IEEE 802.16 network whereas IEEE 802.3 network does not have explicitly required connection procedures. The BS and MSs negotiate and configure parameters such as radio frequency, synchronization for physical layer frame, duplex method, power level, modulation and demodulation scheme, CS types and so on during the network entry procedures. When network entry procedures are completed, BS maintains connection identifier (CID) and media access control (MAC) address for each MS. Also, the BS reports required such information as CID, MAC, CS type and IP address to connected ACR. 4.1. Requirements for HBPD in IEEE 802.16 Networks After the successful network entry procedures at MS, network equipment SHOULD maintain following information. The ACR is a first hop router for MS. Kim & Yoon Expires May 8, 2008 [Page 6] Internet-Draft IP Transmission over IEEE 802.16 November 2007 The MS requires following functions. R1: The each MS SHOULD maintain CID and IP address. The BS requires following functions. R1: The BS SHOULD maintain a pair of CID and IP address of MSs that connected BS. R2: The BS SHOULD maintain a pair of MAC address and IP address of ACR that connected BS. R3: The BS MAY maintain a pair of CID of MSs and GRE key managed by ACR that connected BS. R4: The BS MAY maintain a CS type of MSs. R5: The BS MAY support IP routing capabilities for the interface of ACR that use IP tunnel. The ACR requires following functions. R1: The ACR SHOULD maintain a pair of MAC address of BSs and IP address of MSs. R2: The ACR MAY maintain a pair of IP address of MSs and IP address, GRE key of BSs. When the CH communicates with MS, the packets are forwarded by PBR between ACR and CH via Internet. The ACR sends IP packet to MS and receives from MS via BS either L2 forwarding or IP based tunnel. 4.2. HBPD with L2 forwarding in IEEE 802.16 Networks Figure 3 shows a HBPD with L2 forwarding in the IEEE 802.16 network. The IEEE 802.16 CS type can not identify in the IEEE 802.16 frame. It is managed in the management plane based on information of network entry procedures. The payload type of IEEE 802.3 can identify by type value. The type value is 0X0800 for IPv4 and 0X86DD for IPv6 [EtherType]. Kim & Yoon Expires May 8, 2008 [Page 7] Internet-Draft IP Transmission over IEEE 802.16 November 2007 MS BS ACR |<---- IEEE 802.16 frame ---->|<----- IEEE 802.3 frame ----->| | 802.16 Header | IP packet | | 802.3 Header | IP packet | +--------+---+--+------------+ +----+--+--+----+------------+ | |CID| | | | |DA| |type| | +--------+---+--+------------+ +----+--+--+----+------------+ ^ ^ ^ +--- 16 bits | +--- 16 bits +---------- 48 bits Figure 3: HBPD with L2 forwarding 4.2.1. Uplink HBPD from MS to ACR The MS sends IP packet to the BS with IEEE 802.16 frame. It uses CID that acquires during the network entry procedures. The BS receives an IEEE 802.16 frame which payload is IP packet towards Internet from MS. It searches forwarding database table to find a pair of MAC address and IP address of ACR and and extracts IP packet from IEEE 802.16 frame. After finding the MAC and IP address of ACR, the BS sends IP packets to ACR by IEEE 802.3 frame which payload is IP packet extracted from IEEE 802.16 frame. The type value of IEEE 802.3 frame SHOULD set based on CS type. 4.2.2. Downlink HBPD from ACR to MS The ACR receives the packet of CH from Internet. It checks destination IP address of MS to forward packet to the BS and searches layer 2 forwarding database table to find a pair of destination IP address of MS and MAC address of BS. After finding the IP address of MS and MAC address of BS, the ACR sends IP packets to BS by IEEE 802.3 frame based on layer 2 forwarding database table. The destination MAC address of IEEE 802.3 frame from ACR to BS is a MAC address of appropriate BS. The BS receives an IEEE 802.3 frame which payload is IP packet towards MS from ACR. It searches forwarding database table to find a pair of CID and IP address of MS and extracts IP packet from IEEE 802.3 frame. After finding the IP address and CID of MS, the BS sends IP packets to MS by IEEE 802.16 frame which payload is IP packet extracted from IEEE 802.3 frame. Kim & Yoon Expires May 8, 2008 [Page 8] Internet-Draft IP Transmission over IEEE 802.16 November 2007 4.3. HBPD with IP tunnel in IEEE 802.16 Networks Figure 4 shows a HBPD with IP tunnel in the IEEE 802.16 network. In this scheme, GRE [RFC2890] MAY use between BS and ACR. MS BS ACR |<-- IEEE 802.16 frame -->| <------- IEEE 802.3 frame ------>| |802.16 Header| IP packet | |802.3 Header |tunnel| IP packet | +-------+---+-+-----------+ +---+--+-+----+--+---+-----------+ | |CID| | | | |DA| |type|IP|GRE| | +-------+---+-+-----------+ +---+--+-+----+--+---+-----------+ Figure 4: HBPD with IP tunnel 4.3.1. Uplink HBPD from MS to ACR The MS sends IP packet to the BS with IEEE 802.16 frame. It uses CID that acquires during the network entry procedures. The BS receives an IEEE 802.16 frame which payload is IP packet towards Internet from MS. It searches forwarding database table to find an IP address of ACR that is a first hop router for MSs. After finding the IP address of ACR, the BS sends IP packets to ACR by IEEE 802.3 frame which payload is IP packet extracted from IEEE 802.16 frame. The type value of IEEE 802.3 frame SHOULD set based on CS type. 4.3.2. Downlink HBPD from ACR to MS The ACR receives the packet of CH from Internet. It checks destination IP address of MS to forward packet to the BS and searches GRE key to find a BS that maintains CID and IP address of MSs. After finding the GRE key, the ACR encapsulates IP packets with GRE key and sends a packet to BS by GRE tunnel. The BS receives an GRE tunneled IP packet towards MS from ACR. It searches forwarding database table to find a pair of CID and GRE key of appropriate MS and extract IP packet from GRE. After that, the BS sends IP packets to MS by IEEE 802.16 frame with appropriate CID. 4.4. Consideration for L2 forwarding compared with IP tunnel Kim & Yoon Expires May 8, 2008 [Page 9] Internet-Draft IP Transmission over IEEE 802.16 November 2007 5. Requirement of MS and operation 5.1. Legacy IP device to compatible IEEE 802.16 Some operation system (OS) supports only Ethernet for link layer protocol and other OSs can support direct IP packet over link frame. The Ethernet SHOULD support ARP for IP transmission. Even if the use IP CS in IEEE 802.16, it SHOULD operate ARP to send IP packet. The solution is dummy ARP at the driver for IP CS over IEEE 802.16. 5.2. Dedicated IP device for IEEE 802.16 A dedicated terminal for IEEE 802.16 is not required ARP functions for IP CS. 6. Network entry procedures of IEEE 802.16 Network 6.1. IEEE 802.16 frame format Figure 5 shows an 802.16 frame format that consists of a MAC header, a data payload and cyclic redundancy check (CRC). The CRC field is an option. The CRC SHOULD support in the orthogonal frequency division multiple access (OFDMA). | 48 bits | variable | 32 bits| +-------------------+----------------------------------+--------+ | 802.16 MAC Header | Payload (802.16 messages or IP ) | CRC | +-------------------+----------------------------------+--------+ Figure 5: IEEE 802.16 frame format Table 1 shows well-known CID [IEEE802.16e]. Kim & Yoon Expires May 8, 2008 [Page 10] Internet-Draft IP Transmission over IEEE 802.16 November 2007 +------------------------+-------------+--------------------------+ | CID | hexadecimal | Usage | +------------------------+-------------+--------------------------+ | Initial Ranging | 0000 | RNG | | Basic CID | 0001 ~ m | SBC | | Primary management | m+1 ~ 2m | PKM, REG, DSx | | Transport CIDs | 2m+1 ~ FE9F | IP | | Multicast | FEA0 ~ FEFE | | | AAS initial ranging | FEFF | | | Multicast polling | FF00~FFF9 | | | Normal mode multicast | FFFA | | | Sleep mode multicast | FFFB | | | Idle mode multicast | FFFC | | | Fragmentable Broadcast | FFFD | | | Padding CID | FFFE | | | Broadcast CID | FFFF | DL-MAP, UL-MAP, DCD, UCD | +------------------------+-------------+--------------------------+ Table 1: Usage of CIDs 6.2. Network entry procedures of IEEE 802.16 Figure 6 shows an example of network entry procedures for IEEE 802.16. The BS synchronize with MS in the IEEE 802.16 network. The BS sends downlink map (DL-MAP) and uplink map (UL-MAP) messages every frame. The BS sends uplink channel descriptor (UCD) and downlink channel descriptor (DCD) messages periodically. The MS receives frames and finds out following information. A DCD messages composes of information on transit time and receive time for duplex, center frequency, mobility function, BS identification, calculation method of radio signal, downlink burst profiles, and so on. An UCD messages composes of information on uplink burst profile, contention-based reservation timeout, handover ranging, ranging codes, initial ranging intervals, power adjustment and report and so on. The MS sends a ranging (RNG) request messages with requested burst profile, MAC address of MS, MAC version from MS and receives RNG response (RNG-RSP) messages with ranging status, burst profile, MAC address of MS, basic CID and primary management CID from the BS. Kim & Yoon Expires May 8, 2008 [Page 11] Internet-Draft IP Transmission over IEEE 802.16 November 2007 MS BS | | |<------------------------ DL-MAP, UL-MAP ------+ | | |<------------------- DL-MAP, UL-MAP, DCD ------+ | | |<------------------- DL-MAP, UL-MAP, UCD ------+ | | +------ RNG-REQ, UL-MAP, DL-MAP --------------->| |<--------------- DL-MAP, UL-MAP, RNG-RSP ------+ | | +------ SBC-REQ, UL-MAP, DL-MAP --------------->| |<--------------- DL-MAP, UL-MAP, SBC-RSP ------+ | | +------ PKM-REQ, UL-MAP, DL-MAP --------------->| |<--------------- DL-MAP, UL-MAP, PKM-RSP ------+ | | +------ REG-REQ, UL-MAP, DL-MAP --------------->| |<--------------- DL-MAP, UL-MAP, REG-RSP ------+ | | |<--------------- DL-MAP, UL-MAP, DSA-REQ ------+ +------ DSA-RSP, UL-MAP, DL-MAP --------------->| |<--------------- DL-MAP, UL-MAP, DSA-ACK ------+ | | +<---------- IP address configuration --------->| | | v v time Figure 6: Example of Network Entry Procedures for IEEE 802.16 The MS sends a SS basic capability (SBC) request messages with subscriber transition gap, maximum transmit power, current transmitted power, OFDMA parameters such as FFT sizes, modulator, demodulator, CINR measurement capability, handover trigger metric and so on. It receives a SBC response (SBC-RSP) messages with subscriber transition gap, security negotiation parameters such as PKM version, authorization policy, message authentication code, OFDMA parameters such as FFT sizes, modulator, demodulator, CINR measurement capability and so on from the BS. The MS sends privacy key management (PKM) request message with PKM identifier, payload that depends on authorization policy such as EAP or RSA in SBC-RSP. It receives a PKM response (PKM-RSP) messages with PKM identifier and payload from the BS. After that, the MS exchanges additional information such as key sequence number, lifetime, PKM configuration and so on. Kim & Yoon Expires May 8, 2008 [Page 12] Internet-Draft IP Transmission over IEEE 802.16 November 2007 The MS sends registration (REG) request messages with information on number of uplink and downlink transport CIDs, supported mobility features, support of CS classification such as IPv4, IPv6, IPv6 over 802.3, IPv6 over 802.3 and more, maximum number of classifiers, idle mode timeout, total number of provisioned service flow and so on. The MS receives a REG response (REG-RSP) messages with information on requested parameters and additional parameters such as system resource retain time, handover retransmission timer and so on. After the MS successfully registers to the BS, the BS sends a dynamic service addition (DSA) request messages with transaction identifier, uplink and downlink service flows. A service flow information composes of service flow identification, CID for IP, service flow name, QoS parameters such as traffic priority, maximum sustained traffic rate, maximum traffic burst,tolerated jitter, maximum latency, CS specification, type of delivery, ARQ parameters, packet classification rule and so on. The MS responses to the BS by DSA response (DSA-RSP) messages with same transaction identifier of DSA-REQ and confirmation code. The BS replys DSA acknowledge (DSA-ACK) messages with same transaction identifier of DSA-RSP and confirmation code. The MS acquires IP address in accordance with IP CS. 6.3. Network entry for IPv4 CS The MS sends REG-REQ message that SHOULD set the bit #1 for type 7 for IPv4 packet transmission shown in Figure 7. The BS responses REG-RSP messages that SHOULD set the bit #1 of type 7 as shown in Figure 7. | type | length | value (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 1 1|0 0 0 0 0 0 1 0| | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ IPv6 packet ---+ | IPv4 packet -----+ Figure 7: Type 7 for Classification Support in REG Message The BS sends DSA-REQ messages that SHOULD set the value for IPv4 to one of type 28 as shown in Figure 8. It MAY send uplink and downlink parameters separately. Kim & Yoon Expires May 8, 2008 [Page 13] Internet-Draft IP Transmission over IEEE 802.16 November 2007 | type | length | value (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 1 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Type 28 for IPv4 CS Specification in DSx Message In case of IPv4 CS, the packet classification rules SHOULD identify with 145.100 for IPv4 packet of uplink and 146.100 for IPv4 packet of downlink in the DSA-REQ messages. The IPv4 packet classification rules SHOULD have a packet classification rule priority and index, IPv4 address and mask as shown in Figure 9. | type | length | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 0 0 1 0 0|0 0 0 1 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1|0 0 0 1 0 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1|0 0 0 0 1 0 0 0| IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | IPv4 address mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0| classification rule index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: An Example of IPv4 packet classification rule The encoding type '145.100.3.1' identifies priority of packet classification rule for IPv4 packet of uplink. The default priority value is zero and higher value indicates higher priority. The encoding type '145.100.3.5' identifies IPv4 destination address of packet classification rule for uplink. This parameter specifies a list of IPv4 destination address and their masks. The encoding type '145.100.3.14' identifies an index of IPv4 packet classification rule for uplink. It is unique per service flow. The BS and MS SHOULD maintain at least one service flow for IPv4 CS. Kim & Yoon Expires May 8, 2008 [Page 14] Internet-Draft IP Transmission over IEEE 802.16 November 2007 6.4. Network entry for IPv6 CS The MS sends REG-REQ message that SHOULD set the bit #2 for type 7 for IPv6 packet transmission. The BS responses REG-RSP messages that SHOULD set the bit #2 of type 7 as shown in Figure 7. The BS sends DSA-REQ messages that SHOULD set the value for IPv6 to two of type 28 which is CS specification. It MAY send uplink and downlink parameters separately. In case of IPv6 CS, the packet classification rules SHOULD identify with 145.101 for IPv6 packet of uplink and 146.101 for IPv6 packet of downlink in the DSA-REQ messages. The IPv6 packet classification rules SHOULD have a packet classification rule priority and index, IPv6 address and mask as shown in Figure 10. The encoding type '145.101.3.1' identifies priority of packet classification rule for IPv6 packet of uplink. The default priority value is zero and higher value indicates higher priority. The encoding type '145.101.3.5' identifies IPv6 destination address of packet classification rule for uplink. This parameter specifies a list of IPv6 destination address and their masks. The encoding type '145.101.3.14' identifies an index of IPv6 packet classification rule for uplink. It is unique per service flow. The BS and MS SHOULD maintain global unicast IPv6 address. The BS and MS MAY maintain link local IPv6 address. Kim & Yoon Expires May 8, 2008 [Page 15] Internet-Draft IP Transmission over IEEE 802.16 November 2007 | type | length | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 1 0 0 1 0 1|0 0 0 1 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1|0 0 1 0 1 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1|0 0 1 0 0 0 0 0| Link local IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Link local IPv6 address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link local IPv6 address | IPv6 address mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IPv6 address mask ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0| classification rule index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 1|0 0 1 0 1 0 0 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 1| priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 1|0 0 1 0 0 0 0 0| Global unicast IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Global unicast IPv6 address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global unicast IPv6 address | IPv6 address mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IPv6 address mask ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0| classification rule index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: An Example of IPv6 packet classification rule Kim & Yoon Expires May 8, 2008 [Page 16] Internet-Draft IP Transmission over IEEE 802.16 November 2007 6.5. Network entry for IPv4 and IPv6 dual CS The MS sends REG-REQ message that SHOULD set the bit #1 and the bit #2, value six, for type 7 for both IPv4 and IPv6 packet transmission. The BS responses REG-RSP messages that SHOULD set the value six to type 7. The REG-REQ and REG-RSP MAY exchange one time to indicate dual stack support with value six. The DSA messages MAY exchange either one time or two times for dual stack. When the DSA messages exchanges one time, DSA-REQ messages SHOULD set the value for IPv4 to two of type 28 which is CS specification. The BS sends DSA-REQ messages that SHOULD set the value for IPv6 to two of type 28 which is CS specification. It MAY send uplink and downlink parameters separately. It is unique per service flow. The BS and MS SHOULD maintain at least two service flow for dual stack: One is for global IPv6 address and the other is IPv4 address. 7. Security Considerations The address masks set to control IP packet at classification rule in DSx messages. It is recommended that an address mask is all 1 to prevent IP spoofing on the IEEE 802.16 network. This method allows that MS and BS transmit specified IP address. When an MS supports IPv6 CS or dual stack, [RFC4941] MAY use for privacy. The DSC messages SHOULD be exchanged between MS and BS after IPv6 addresses generated by [RFC4941]. 8. IANA Considerations This document requests no action by IANA. 9. Acknowledgements The author would like to acknowledge to initial discussion members who are Soohong Daniel Park, Gabrial Montenegro, Jihoon Lee, Riegel Maximilian, Kosuke Ito. 10. References Kim & Yoon Expires May 8, 2008 [Page 17] Internet-Draft IP Transmission over IEEE 802.16 November 2007 10.1. Normative References [IEEE802.16] "IEEE Standard for Local and metropolitan area networks - Specific requirements - Part 16: Air Interface for Fixed Broadband Wireless Access Systems", IEEE Standard 802.16, June 2004. [IEEE802.16e] "IEEE Standard for Local and metropolitan area networks - Specific requirements - Part 16: Air Interface for Fixed Broadband Wireless Access Systems, Amendment 2: Physical and Medium Access Control layers for Combined Fixed and Mobile Operation in Licensed bands and Corrigendum 1", IEEE Standard 802.16e, December 2005. [IEEE802.3] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Standard 802.3, March 2002. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. Kim & Yoon Expires May 8, 2008 [Page 18] Internet-Draft IP Transmission over IEEE 802.16 November 2007 10.2. Informative References [EtherType] Internet Assigned Numbers Authority, "http://www.iana.org/assignments/ethernet-numbers". Authors' Addresses Sang-Eon Kim Infra Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-792 Korea Phone: +82 2 526 6117 Fax: +82 2 526 5200 Email: sekim@kt.co.kr Joo Young Yoon Infra Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul, 137-792 Korea Phone: +82 2 526 6244 Fax: +82 2 526 5200 Email: jyyoon@kt.co.kr Kim & Yoon Expires May 8, 2008 [Page 19] Internet-Draft IP Transmission over IEEE 802.16 November 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). Kim & Yoon Expires May 8, 2008 [Page 20]