idnits 2.17.1 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 28, 2007) is 6150 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-16ng-ps-goals-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 16ng Working Group S. Madanapalli 3 Internet-Draft Ordyn Technologies 4 Intended status: Standards Track Soohong D. Park 5 Expires: November 29, 2007 Samsung Electronics 6 S. Chakrabarti 7 Azaire Networks 8 May 28, 2007 10 Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer 11 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 29, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 IEEE 802.16 is an air interface specification for wireless broadband 45 access. IEEE has specified the service specific convergence 46 sublayers (CS) in the IEEE 802.16 MAC to be used by upper layer 47 protocols. Asynchronous Transfer Mode Convergence Sublayer (ATM CS) 48 and Packet Convergence Sublayer (Packet CS) represent the two main 49 service specific convergence sublayers for the IEEE 802.16. The 50 packet CS is used for transport for all packet-based protocols such 51 as Internet Protocol (IP), IEEE 802.3 (Ethernet) and IEEE 802.1Q 52 (VLAN). The IP specific part of the Packet CS enables transport of 53 IPv4 packets directly over the IEEE 802.16 MAC. 55 This document specifies the frame format, the Maximum Transmission 56 Unit (MTU) and address assignment procedures for transmitting IPv4 57 packets over IP Convergence Sublayer (IPCS) of the IEEE 802.16. This 58 document also provides the details of why the ARP cannot be sent over 59 the IEEE 802.16 links using IPCS and a recommendation for this. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Typical Network Architecture for IPv4 over IEEE 802.16 . . . . 3 66 4. Frame Format for IPv4 Packets . . . . . . . . . . . . . . . . 4 67 5. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5 68 6. Subnet Model and IPv4 Address Assignment . . . . . . . . . . . 5 69 7. Address Resolution Protocol . . . . . . . . . . . . . . . . . 6 70 8. IP Multicast Address Mapping . . . . . . . . . . . . . . . . . 6 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 12.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Appendix A. Multiple Convergence Layers - Impact on Subnet 78 Model . . . . . . . . . . . . . . . . . . . . . . . . 7 79 Appendix B. Consideration for ARP Implementation . . . . . . . . 8 80 Appendix C. Sending and Receiving IPv4 Packets . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 Intellectual Property and Copyright Statements . . . . . . . . . . 10 84 1. Introduction 86 IEEE 802.16 [7] is a connection oriented access technology for the 87 last mile without bi-directional native multicast support. IEEE 88 802.16 has only downlink multicast support and there is no mechanisms 89 defined for mobile stations to be able to send multicast packets that 90 can be mapped to downlink multicast connection. And also IEEE 802.16 91 MAC does not use the Source and Destination MAC addresses, instead it 92 uses the Connection Identifiers (CIDs), which are assigned 93 dynamically while setting up the MAC connections, for transmitting 94 the IEEE 802.16 frames between a Mobile Station (MS) and a Base 95 Station (BS). 97 This document specifies a method for encapsulating and transmitting 98 IPv4 [2] and Address Resolution Protocol (ARP) packets over IP CS of 99 IEEE 802.16. This document also specifies the MTU and address 100 assignment method for the IEEE 802.16 based networks using IPCS. As 101 the IEEE 802.16 MAC does not use the source and destination MAC 102 addresses for the frame transmission, this document recommends 103 avoiding ARP and Mapping of multicast IP address to MAC address. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [1]. 109 2. Terminology 111 The terminology in this document is based on the definitions in [10], 112 in addition to the ones specified in this section. 114 Access Router (AR): An entity that performs an IP routing function to 115 provide IP connectivity for Mobile Stations. 117 3. Typical Network Architecture for IPv4 over IEEE 802.16 119 In a network that utilizes the IEEE 802.16 air interface, each MS is 120 attached to an Access Router (AR) through a Base Station (BS), a 121 layer 2 entity. The AR can be an integral part of the BS or the AR 122 could be an entity beyond the BS within the access network. IPv4 123 packets between the MS and BS are carried over a point-to-point MAC 124 transport connection which has a unique connection identifier (CID). 125 The packets between BS and AR are carried using L2 tunnel (typically 126 GRE tunnel) so that MS and AR are seen as layer 3 peer entities. At 127 least one L2 tunnel is required for each MS, so that IP packets can 128 be sent to MSs before they acquire IP addresses. The figure below 129 illustrates the network architecture. 131 +-----+ CID1 +------+ +-----------+ 132 | MS1 |----------+| BS |----------| AR |-----Internet 133 +-----+ / +------+ +-----------+ 134 . / ____________ 135 . CIDn / ()__________() 136 +-----+ / L2 Tunnel 137 | MSn |-----/ 138 +-----+ 140 Figure 1: Typical Network Architecture for IPv4 over IEEE 802.16 142 The above network model serves as an example and is shown to 143 illustrate the point to point link between the MS and the AR. The L2 144 tunnel is not required if BS and AR are integrated into a single box. 146 4. Frame Format for IPv4 Packets 148 IPv4 packets are transmitted in Generic IEEE 802.16 MAC frames as 149 shown in the following figure. 151 0 1 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |H|E| TYPE |R|C|EKS|R|LEN | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | LEN LSB | CID MSB | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | CID LSB | HCS | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | IPv4 | 161 +- -+ 162 | header | 163 +- -+ 164 | and | 165 +- -+ 166 / payload / 167 +- -+ 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |CRC (optional) | 171 +-+-+-+-+-+-+-+-+ 173 Figure 2: IEEE 802.16 MAC Frame Format for IPv4 Packets 175 H: Header Type (1 bit). Shall be set to zero indicating that it 176 is a Generic MAC PDU. 177 E: Encryption Control. 0 = Payload is not encrypted; 1 = Payload 178 is encrypted. 179 R: Reserved. Shall be set to zero. 180 C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included 181 EKS: Encryption Key Sequence 182 LEN: The Length in bytes of the MAC PDU including the MAC header 183 and the CRC if present (11 bits) 184 CID: Connection Identifier (16 bits) 185 HCS: Header Check Sequence (8 bits) 186 CRC: An optional 8-bit field. CRC appended to the PDU after 187 encryption. 188 TYPE: This field indicates the subheaders (Mesh subheader, 189 Fragmentation Subheader, Packing subheader etc and special payload 190 types (ARQ) present in the message payload 192 5. Maximum Transmission Unit 194 The Length parameter of IEEE 802.16 MAC frame has a size of 11 bits. 195 Hence the total PDU size is 2048 bytes. The IPv4 payload can be a 196 maximum value of 2038 bytes ( Total PDU size (2048) - (MAC Header (6) 197 + CRC (4)), which is the maximum possible MTU. The minimum MTU 198 required for IPv4 is 576 bytes [4]. The default MTU value of 1400 199 bytes SHOULD be used so that it is most likely that the packets are 200 not fragmented between BS and AR when Ethernet is used for transport. 201 The actual MTU value can be set by the Path MTU Discovery [9] or by 202 manual configuration of each MS. 204 6. Subnet Model and IPv4 Address Assignment 206 The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is 207 based on point-to-point link between MS and AR, hence each MS shall 208 be on different IP subnet. The point-to-point link between MS and AR 209 is achieved using a set of IEEE 802.16 MAC connections (identified by 210 CIDs) and at least an L2 tunnel (usually GRE tunnel) per MS between 211 BS and AR. If the AR is co-located with the BS then the set of IEEE 212 802.16 MAC connections between the MS and BS/AR represent the 213 point-to- point connection. 215 DHCP [5] SHOULD be used for assigning IPv4 address for the MSs. DHCP 216 messages are transported over IEEE 802.16 MAC transported connection 217 to and from the AR. In case DHCP server does not reside in AR, the 218 AR SHOULD implement DHCP relay Agent [6]. 220 7. Address Resolution Protocol 222 The IEEE 802.16 frame header does not contain the source and 223 destination MAC addresses, instead it uses the Connection Identifier 224 (CID) for the delivery of MAC frames. This makes classical Address 225 Resolution Protocol (ARP) [3] trivial and unnecessary. > Also, IEEE 226 802.16 IPCS cannot classify the ARP packets as ARP runs directly over 227 Ethernet and does not contain IP header. Thus ARP packets are not 228 transmitted over IEEE 802.16 air interface when using IPCS. 230 8. IP Multicast Address Mapping 232 In IEEE 802.16, MAC address is not user for delivering the frames as 233 well as there is no concept of multicast MAC address. Hence, the 234 Mapping of multicast IP address to an IEEE 802.16 MAC address is not 235 required. The IPv4 multicast packets are classified normally at the 236 IPCS if the IEEE 802.16 MAC connection has been setup with a 237 multicast IP address as a classification parameter for the 238 destination IP address. 240 9. Security Considerations 242 This document specifies transmission of IPv4 packets over IEEE 802.16 243 networks with IPv4 Convergence Sublayer and does not introduce any 244 new vulnerabilities to IPv4 specifications or operation. The 245 security of the IEEE 802.16 air interface is the subject of [7]. In 246 addition, the security issues of the network architecture spanning 247 beyond the IEEE 802.16 base stations is the subject of the documents 248 defining such architectures, such as WiMAX Network Architecture [8]. 250 10. IANA Considerations 252 This document has no actions for IANA. 254 11. Acknowledgements 256 The authors would like to acknowledge the contributions of Bachet 257 Sarikaya, Basavaraj Patil, Paolo Narvaez, Bruno Sousa and Bernard 258 Aboba for their review and comments. 260 12. References 261 12.1. Normative References 263 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 264 Levels", BCP 14, RFC 2119, March 1997. 266 [2] Postel, J., "Internet Protocol", STD 5, RFC 791, 267 September 1981. 269 [3] Plummer, D., "Ethernet Address Resolution Protocol: Or 270 converting network protocol addresses to 48.bit Ethernet 271 address for transmission on Ethernet hardware", STD 37, 272 RFC 826, November 1982. 274 [4] Braden, R., "Requirements for Internet Hosts - Communication 275 Layers", STD 3, RFC 1122, October 1989. 277 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 278 March 1997. 280 [6] Wimer, W., "Clarifications and Extensions for the Bootstrap 281 Protocol", RFC 1542, October 1993. 283 12.2. Informative References 285 [7] "IEEE 802.16e, IEEE standard for Local and metropolitan area 286 networks, Part 16:Air Interface for fixed and Mobile broadband 287 wireless access systems", October 2005. 289 [8] "WiMAX End-to-End Network Systems Architecture Stage 2-3 290 Release 1.0.0, http://www.wimaxforum.org/technology/documents", 291 March 2007. 293 [9] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 294 November 1990. 296 [10] Jee, J., "IP over 802.16 Problem Statement and Goals", 297 February 2007, . 300 [11] Aboba, B., Davies, E., and D. Thaler, "Multiple Encapsulation 301 Methods Considered Harmful", RFC 4840, April 2007. 303 Appendix A. Multiple Convergence Layers - Impact on Subnet Model 305 Two different MSs using two different convergence sublayers (e.g. an 306 MS using Ethernet CS only and another MS using IP CS only) cannot 307 communicate at data link layer and requires interworking at IP layer. 309 For this reason, these two nodes must be configured to be on two 310 different subnets. For more information refer [11]. 312 Appendix B. Consideration for ARP Implementation 314 A node may trigger ARP for address resolution when there is no 315 corresponding entry in ARP cache, in such cases, the node should 316 synthesize the ARP response locally for smooth operation of IP layer. 318 Appendix C. Sending and Receiving IPv4 Packets 320 IEEE 802.16 MAC is a point-to-multipoint connection oriented air- 321 interface, and the process of sending and receiving of IPv4 packets 322 is different from multicast capable shared medium technologies like 323 Ethernet. 325 Before any packets being transmitted, IEEE 802.16 transport 326 connection must be established. This connection consists of IEEE 327 802.16 MAC transport connection between MS and BS and an L2 tunnel 328 between BS and AR. This IEEE 802.16 transport connection provides a 329 point-to-point link between MS and AR. all the packets originated at 330 the MS always reach AR before being transmitted to the final 331 destination. 333 IPv4 packets are carried directly in the payload of IEEE 802.16 334 frames when the IPv4 CS is used. IPv4 CS classifies the packet based 335 on upper layer (IP and transport layers)header fields to put the 336 packet on one of the available connections identified by the CID. 337 The classifiers for the IPv4 CS are source and destination IPv4 338 addresses, source and destinations ports, Type-of-Service and IP 339 protocol field. The CS may employ Packet Header Suppression (PHS) 340 after the classification. 342 The BS tunnels the packet that has been received on a particular MAC 343 connection to the AR. BS reconstructs the payload header if the PHS 344 is in use before the packet is tunneled to the AR. Similarly the 345 packets received on a tunnel interface from the AR, would be mapped 346 to a particular CID using IPv4 classification mechanism. 348 AR performs normal routing for the packets that it receives and 349 forwards the packet based on its forwarding table. However the DHCP 350 relay agent in the AR, MUST maintain the tunnel interface on which it 351 receives DHCP requests, so that it can relay the DHCP responses to 352 the correct MS. One way of doing this is to have a mapping between 353 MAC address and Tunnel Identifier. 355 Authors' Addresses 357 Syam Madanapalli 358 Ordyn Technologies 359 1st Floor, Creator Building, ITPL 360 Bangalore - 560066 361 India 363 Email: smadanapalli@gmail.com 365 Soohong Daniel Park 366 Samsung Electronics 367 416 Maetan-3dong, Yeongtong-gu 368 Suwon 442-742 369 Korea 371 Email: soohong.park@samsung.com 373 Samita Chakrabarti 374 Azaire Networks 375 3121 Jay Street 376 Santa Clara, CA 377 USA 379 Email: samitac2@gmail.com 381 Full Copyright Statement 383 Copyright (C) The IETF Trust (2007). 385 This document is subject to the rights, licenses and restrictions 386 contained in BCP 78, and except as set forth therein, the authors 387 retain all their rights. 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 392 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 393 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 394 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Intellectual Property 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at 419 ietf-ipr@ietf.org. 421 Acknowledgment 423 Funding for the RFC Editor function is provided by the IETF 424 Administrative Support Activity (IASA).