idnits 2.17.1 draft-mandin-ip-over-80216-ethcs-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 425. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 16, 2005) is 6767 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mandin 3 Internet-Draft Runcom 4 Expires: April 19, 2006 October 16, 2005 6 Transport of IP over 802.16 7 draft-mandin-ip-over-80216-ethcs-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 In this memo we describe a simple scheme for configuration and 41 provisioning of an 802.16 network so that it emulates a broadcast 42 network that uses the 802.3 packet format. We briefly describe how 43 this network supports IPv4 and IPv6 services in a manner similar to 44 other broadcast media (eg. ethernet). Finally, we review some 45 architectural issues behind the choice of broadcast network emulation 46 and examine alternative approaches to supporting IP over 802.16. We 47 additionally describe some possible system optimizations to reduce 48 consumption of air resources. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 6 56 4.1. Transport Connections . . . . . . . . . . . . . . . . . . 6 57 4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 6 58 4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 6 59 4.4. Convergence Sublayer Types . . . . . . . . . . . . . . . . 7 60 4.5. Payload Header Suppression . . . . . . . . . . . . . . . . 8 61 5. Supporting IPv4 and IPv6 over 802.16 via Broadcast Network 62 Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. Logical Topology of Simple Broadcast Network Emulation . . 9 64 5.2. IPv4 functions on the 802.16-based broadcast network . . . 10 65 6. Survey of possible alternative approaches . . . . . . . . . . 11 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 68 Appendix A. Deployment considerations for IPv4 . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . . . 16 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 IEEE 802.16-2004 is a specification of the MAC and PHY layers for 82 OFDM and OFDMA-based broadband wireless access. 84 The point-to-multipoint topology of 802.16 raises some interesting 85 questions about how to best support IPv4 and IPv6. IEEE 802.16-2004 86 describes several encapsulation schemes for carrying IP payload data, 87 but does not provide a detailed description of how to support IP 88 transport (and related services such as IP endpoint initialization 89 and IP multicast). 91 In this memo we describe a simple scheme for configuration and 92 provisioning of an 802.16 network so that it emulates a broadcast 93 network that uses the 802.3 packet format. We briefly describe how 94 this network supports IPv4 and IPv6 services in a manner similar to 95 other broadcast media (eg. ethernet). Finally, we review some 96 architectural issues behind the choice of broadcast network emulation 97 and examine alternative approaches to supporting IP over 802.16. We 98 additionally describe some possible system optimizations to reduce 99 consumption of air resources. 101 3. Terminology 103 BS - Base Station 105 PHS - Payload Header Suppression 107 PDU - Protocol Data Unit. This refers to the data format passed from 108 the lower edge of the 802.16 MAC to the 802.16 PHY, which typically 109 contains SDU data after fragmentation, encryption, etc. 111 SDU - Service Data Unit. This refers to the data format passed to 112 the upper edge of the 802.16 MAC 114 SS - Subscriber Station 116 4. Overview of the IEEE 802.16-2004 MAC layer 118 The topology of the IEEE 802.16-2004 network is point-to-multipoint 119 (PMP): a Base Station (BS) communicates with a number of Subscriber 120 Stations (SSes). Each node in the network possesses a 48-bit MAC 121 address (though in the Base Station this 48-bit unique identifier is 122 called "BSId"). Each node possesses an x.509 certificate attesting 123 to its MAC address/BSId. The BS and SS learn each others' MAC 124 Address/BSId during the SS's entry into the network. 126 4.1. Transport Connections 128 User data traffic (in both the BS-bound and SS-bound directions) is 129 carried on unidirectional "transport connections". Each transport 130 connection has a particular set of associated parameters indicating 131 characteristics such as cryptographic suite and quality-of-service. 133 After successful entry of a SS to the 802.16 network, no data traffic 134 is possible - as there are as yet no transport connections between 135 the BS and SS. Transport connections are established by a 3-message 136 signalling sequence within the MAC layer (usually initiated by the 137 BS). 139 A downlink-direction transport connection is regarded as "multicast" 140 if it has been made available (via MAC signaling) to more than one 141 SS. Uplink-direction connections are always unicast. 143 4.2. 802.16 PDU format 145 An 802.16 PDU (ie. the format that is transmitted over the airlink) 146 consists of a 6-byte MAC header, various optional subheaders, and a 147 data payload. 149 The 802.16 6-byte MAC header carries the Connection Identifer (CID) 150 of the connection with which the PDU is associated. We should 151 observe that there is no source or destination address present in the 152 raw 802.16 MAC header. 154 4.3. 802.16 Convergence Sublayer 156 The 802.16 convergence sublayer (CS) is the component of the MAC that 157 is responsible for assigning transmit-direction SDUs (originating 158 from a higher layer application - eg. an IP stack at the BS or SS) to 159 a specific outbound transport connection. 161 The convergence sublayer maintains an ordered "classifier table". 162 Each entry in the classifier table includes a classifier and a target 163 CID. A classifier, in turn, consists of a conjunction of one or more 164 subclassifiers - where each subclassifier specifies a packet field 165 (eg. the destination MAC address in an ethernet frame, or the TOS 166 field of an IP datagram contained in an ethernet frame) together with 167 a particular value or range of values for the field. 169 To perform classification on an outbound SDU, the convergence 170 sublayer proceeds from the first entry of the classifier table to the 171 last, and evaluates the fields of the SDU for a match with the table 172 entry's classifier When a match is found, the convergence sublayer 173 associates the SDU with the target CID (for eventual transmission), 174 and the remainder of the 802.16 MAC and PHY processing can take 175 place. 177 The convergence sublayer includes an important additional function: 178 payload header suppression (see section 2.5). 180 4.4. Convergence Sublayer Types 182 802.16 defines numerous convergence sublayer types. The "type" of 183 the convergence sublayer determines the fields that may appear in 184 classifiers eg. 186 o "802.3/Ethernet CS" permits classifiers that examine fields in 187 802.3-style headers 189 o "IPv4-over-ethernet CS" permits classifiers that examine fields in 190 ethernet headers as well as fields of IPv4 (and encapsulated TCP/ 191 UDP headers) that are encapsulated in 802.3-style frames 193 o "IPv6-over-ethernet CS" permits classifiers that examine fields in 194 ethernet headers as well as fields of IPv6 (and encapsulated TCP/ 195 UDP headers) that are encapsulated in 802.3-style frames 197 Other CS types include ATM and "raw" IPv4/IPv6. An implementation of 198 802.16 can support multiple CS types. 200 We can observe that the CS type actually defines the type of data 201 interface (eg. 802.3) that is presented by 802.16 to the higher layer 202 application. 204 We can also observe that the forwarding mechanism of 802.16 makes no 205 distinction between assigning an outbound SDU to a particular 206 destination, assigning it to a particular multicast group, and 207 assigning it to a particular class of service - the mechanism is 208 precisely the same in all these cases. 210 4.5. Payload Header Suppression 212 One or more rules for payload header suppression (PHS) may be 213 optionally associated with an outbound connection. A PHS rule 214 includes: 216 o a bit mask and a corresponding bit pattern (typically 217 corresponding to frequently recurring sequence of bytes in the 218 "header portion" of the SDU payload - such as the 14 bytes of an 219 802.3 header) 221 o a target "PHS index" (to be carried as the first byte of the 222 PHS-ed SDU) 224 In an example where there is a single PHS rule defined for a 225 particular connection, the convergence sublayer (after determining 226 that an SDU matches a particular entry in the classifier table), 227 checks whether the SDU does in fact include the "suppressable" 228 pattern indicated by the PHS rule. To perform suppression, the 229 convergence sublayer removes the suppressable pattern from the SDU 230 and prepends the PHS Index before moving the SDU forward for the 231 remainder of the MAC and PHY processing. 233 The illustration below compares the format of the non-PHS-ed and 234 PHS-ed SDU formats: 236 5. Supporting IPv4 and IPv6 over 802.16 via Broadcast Network Emulation 238 5.1. Logical Topology of Simple Broadcast Network Emulation 240 When properly configured and assisted by a simple bridging function, 241 802.16 can emulate a simple broadcast network. Specifically: 243 o The 802.16 network must be configured (ie. via network management) 244 with transport connections using an appropriate choice from the 245 802.3/ethernet CS types (eg. "IPv4 over ethernet"). The 246 transport connections must be configured to forward 802.3 frames 247 so that: 249 * outbound frames from the BS that contain a particular unicast 250 destination MAC address are forwarded on a transport connection 251 to the SS that bears that specific MAC address 253 * outbound frames from the BS that contain a non-unicast 254 destination MAC address are forwarded on a transport connection 255 that is received by all SSes 257 * outbound frames from the SS are always forwarded on a 258 particular transport connection to the BS 260 o The BS must include an additional functional entity above the BS 261 MAC layer to perform MAC bridging (for example: in conformance 262 with IEEE 802.1D and operating as a learning bridge) 264 o Optionally: The 802.16 network can be configured (ie. via network 265 management) with a payload header suppression (PHS) rule for each 266 connection - so as to eliminate the most common value for the 14- 267 byte 802.3 header (ie. the one containing the MAC address of the 268 SS, the MAC address of the access router, and 0x0800 ethertype). 269 In this way, we cause the 14 bytes of 802.3 overhead to be 270 replaced with a single byte of PHS overhead. 272 Additionally, network management may configure more than one 273 transport connection to/from a particular SS (ie. to support 274 diffentiated classes of service) without impacting the basic 275 behaviour of the broadcast network emulation. 277 If future amendments to 802.16 were to include support for robust 278 header compression (ROHC), then ROHC could be used instead of PHS (or 279 perhaps in conjunction with it) to efficiently control both 802.3 and 280 IP header overhead. 282 5.2. IPv4 functions on the 802.16-based broadcast network 284 If we consider an IPv4 subnet based on the broadcast network 285 described above, we will expect a standard IP host stack on each of 286 the SSes, and an access router either co-located with the BS or on a 287 bridged or tunnelled network behind it. 289 IPv4 functions over this network are straightforward: 291 o IP endpoint management messages (whether DHCP, Mobile IP, or what 292 have you) are carried over default transport connections in the 293 uplink direction and MAC-address based unicast transport 294 connections in both the downlink directions 296 o Unicast IP traffic between the subscriber-side IP hosts and the 297 access router is carried on default transport connections in the 298 uplink direction and on MAC-address based unicast transport 299 connections in both the downlink direction 301 o Subnet-wide broadcasts from the access router (such as ICMP router 302 advertisements) are transmitted over the downlink multicast 303 transport connection and received by all subscriber-side IP hosts 305 o IP multicast traffic from the access router will be carried over 306 the downlink multicast transport connection, and can be received 307 by subscriber-side IP hosts that are listening for MAC messages 308 with the particular multicast MAC address 310 o Subscriber-originated broadcasts (eg. ARP), and unicast or 311 multicast datagrams to subnet peers are transmitted up to the BS 312 and back down over the appropriate transport connection by the 313 bridging function 315 o Subscriber-side IP hosts may receive ICMP-redirect from the access 316 router and can begin to use a new access router. 318 6. Survey of possible alternative approaches 320 There are a few ways that the 802.16 PMP network can be represented 321 in terms of "IP links" (or "IP subnets"). 323 Separating the PMP network into a series of IP point-to-point links 324 is possible in 802.16 using PPPoE. Using PPP directly is not 325 feasible in 802.16 because there is no convergence sublayer that 326 permits classification to transport connections based on fields in a 327 PPP header. As well, this approach does not make use of the downlink 328 direction multicast capability. 330 The NBMA model does not seem relevant to 802.16, as in NBMA networks 331 - unlike 802.16 PMP - a direct unicast connection is available 332 between network nodes. 334 An alternative approach to broadcast network emulation involves the 335 use of the "Raw IP" convergence sublayer. Rather than suppressing or 336 compressing the 802.3 header from transported SDUs on a 802.3-CS- 337 based transport connection, this approach transports only IP 338 datagrams - on "raw IP"-CS-based connections. The identities of the 339 L2 endpoints are then reconstructed at either end of the airlink 340 based on the L3 information. This approach is problematic however as 341 it seems to be impossible to fully abandon the notion of explicit L2 342 addresses - most notably in IPv6 neighbor discovery messages (which 343 carry L2 addresses directly), but also in various IPv4 IP address 344 management protocols such as DHCP and Mobile IP registrations. 346 7. Security Considerations 348 TBD 350 8. Acknowledgements 352 Ideas in this memo have benefitted from discussion in the Ethernet CS 353 subteam of the Wimax Forum Network Working Group (Byoung-Jo Kim, Dave 354 Maez, Max Riegel, N. K. Shankaranarayanan). 356 Appendix A. Deployment considerations for IPv4 358 In a service provider deployment of 802.16, some changes from the 359 subnet scheme described in section 3 will often be desirable. Since 360 these involve placement of functional elements outside of the 802.16 361 network, we describe these in an annex: 363 1. Subscriber-side IP hosts are of course not in the control of the 364 service provider, and might generate spurious broadcast messages 365 (eg. printer announcements). The classifier table at the SS can 366 be configured by network management so as to drop these broadcast 367 frames. 369 2. The service provider might require that all frames (including 370 frames between IP hosts on the same subnet) traverse the access 371 router (eg. for accounting purposes). There are several ways to 372 accomplish this in the context of the emulated broadcast network. 373 The most simple approach is to co-locate the bridging function at 374 the access router (so that all frames must reach the access 375 router where they can be accounted for). Alternatively, the 376 bridging function at the BS could conform to RFC 925 (ARP-based 377 bridging) rather than 802.1D (transparent bridging) - so that 378 once again every frame will traverse the access router. 380 3. ARP broadcasts consume bandwidth on the airlink and are not 381 always necessary. A proxy ARP function at the BS can respond to 382 subscriber side ARPs (thus preventing propagation over the 383 multicast transport connection). As well, a functional elements 384 co-located at the BS, the access router, or somewhere in between 385 can use snooped DHCP of snooped mobile IP information to avoid 386 the need to issue of ARPs from the head-end side of the network. 388 9. References 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 Author's Address 395 Jeff Mandin 396 Runcom 397 Ha-homa 2 398 Rishon Lezion 399 Israel 401 Email: jeff@streetwaves-networks.com 403 Intellectual Property Statement 405 The IETF takes no position regarding the validity or scope of any 406 Intellectual Property Rights or other rights that might be claimed to 407 pertain to the implementation or use of the technology described in 408 this document or the extent to which any license under such rights 409 might or might not be available; nor does it represent that it has 410 made any independent effort to identify any such rights. Information 411 on the procedures with respect to rights in RFC documents can be 412 found in BCP 78 and BCP 79. 414 Copies of IPR disclosures made to the IETF Secretariat and any 415 assurances of licenses to be made available, or the result of an 416 attempt made to obtain a general license or permission for the use of 417 such proprietary rights by implementers or users of this 418 specification can be obtained from the IETF on-line IPR repository at 419 http://www.ietf.org/ipr. 421 The IETF invites any interested party to bring to its attention any 422 copyrights, patents or patent applications, or other proprietary 423 rights that may cover technology that may be required to implement 424 this standard. Please address the information to the IETF at 425 ietf-ipr@ietf.org. 427 Disclaimer of Validity 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 Copyright Statement 439 Copyright (C) The Internet Society (2005). This document is subject 440 to the rights, licenses and restrictions contained in BCP 78, and 441 except as set forth therein, the authors retain all their rights. 443 Acknowledgment 445 Funding for the RFC Editor function is currently provided by the 446 Internet Society.