idnits 2.17.1 draft-ietf-16ng-ps-goals-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. 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 (December 19, 2007) is 5973 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Jee, Editor 2 Internet-Draft ETRI 3 Intended status: Informational S. Madanapalli 4 Expires: June 21, 2008 Ordyn Technologies 5 J. Mandin 6 Runcom 7 December 19, 2007 9 IP over 802.16 Problem Statement and Goals 10 draft-ietf-16ng-ps-goals-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 21, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document specifies problems in running the IETF IP protocols 44 over IEEE 802.16 networks by identifying specific gaps in the 802.16 45 MAC for IPv4 and IPv6 support. This document also provides an 46 overview of IEEE 802.16 network characteristics and convergence 47 sublayers. Common terminology used for the base guideline while 48 defining the solution framework is also presented. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview of the IEEE 802.16 MAC layer . . . . . . . . . . . . 5 55 3.1. Transport Connections . . . . . . . . . . . . . . . . . . 5 56 3.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 5 57 3.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 6 58 4. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 7 59 4.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Point-to-Point Link model for IP CS: Problems . . . . . . 9 61 4.3. Ethernet-like Link model for Ethernet CS: Problems . . . . 10 62 4.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 11 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 71 Intellectual Property and Copyright Statements . . . . . . . . . . 14 73 1. Introduction 75 Broadband Wireless Access networks address the inadequacies of low 76 bandwidth wireless communication for user requirements such as high 77 quality data/voice service, fast mobility, wide coverage, etc. The 78 IEEE 802.16 Working Group on Broadband Wireless Access Standards 79 develops standards and recommended practices to support the 80 development and deployment of broadband Wireless Metropolitan Area 81 Networks [IEEE802.16]. 83 Recently the WiMAX Forum, and in particular, its NWG (Network Working 84 Group) is defining the IEEE 802.16 network architecture (e.g. IPv4, 85 IPv6, Mobility, Interworking with different networks, AAA, etc). The 86 NWG is thus taking on work at layers above those defined by the IEEE 87 802 standards (typically limited to the physical and link-layers 88 only). Similarly, WiBro (Wireless Broadband), a Korean effort which 89 focuses on the 2.3 GHz spectrum band, is also based on the IEEE 90 802.16 specification [IEEE802.16]. 92 802.16 [IEEE802.16] is point-to-point and connection-oriented at the 93 MAC, physically arranged in a point-to-multipoint structure with the 94 BS terminating one end of each connection and an individual SS 95 terminating the other end of each connection. The 802.16 convergence 96 sublayer (CS) is at the uppermost part of the MAC that is responsible 97 for assigning transmit-direction Service Data Units (originating from 98 a higher layer application, e.g., IP or Ethernet at the BS or SS) to 99 a specific outbound transport connection. 802.16 defines two 100 convergence sublayer types, the ATM CS and the Packet CS. The IP 101 Specific Subpart (IP CS) and the 802.3 Ethernet Specific Subpart 102 (Ethernet CS) of Packet CS are within the current 16ng WG scope. 104 There is complexity in configuring the IP Subnet over IEEE 802.16 105 network because of its point-to-point connection-oriented feature and 106 the existence of IP CS and Ethernet CS which assume different higher- 107 layer functionality. An IP Subnet is a topological area that uses 108 the same IP address prefix where that prefix is not further 109 subdivided except into individual addresses as specified in 110 [RFC4903]. The IP Subnet configuration is dependent on the 111 underlying link-layer's characteristic and decides the overall IP 112 operation on the network. The IP CS and Ethernet CS of IEEE 802.16 113 assume different higher layer capabilities: IP routing functionality 114 in the case of IP CS and bridging functionality in the case of 115 Ethernet CS. This means that the link-layer's characteristics 116 beneath IP can change according to the adopted convergence sublayers. 118 This document provides the feasible IP Subnet model for each IP CS 119 and Ethernet CS and specifies the problems in running IP protocols 120 for each case. This document also presents an overview of 802.16 121 network characteristics specifically focusing on the convergence 122 sublayers and the common terminology to be used for the base 123 guideline while defining solution frameworks. 125 2. Terminology 127 Subscriber Station (SS): An end-user equipment that provides 128 connectivity to the 802.16 networks. It can be either fixed/nomadic 129 or mobile equipment. In mobile environment, SS represents the Mobile 130 Subscriber Station (MS) introduced in [IEEE802.16e]. 132 Base Station (BS): A generalized equipment sets that provides 133 connectivity, management, and control between the subscriber station 134 and the 802.16 networks. 136 Access Router (AR): An entity that performs an IP routing function to 137 provide IP connectivity for the subscriber station (SS or MS). 139 Protocol Data Unit (PDU): This refers to the data format passed from 140 the lower edge of the 802.16 MAC to the 802.16 PHY, which typically 141 contains Service Data Unit data after fragmentation, encryption, etc. 143 Service Data Unit (SDU): This refers to the data format passed to the 144 upper edge of the 802.16 MAC 146 IP Subnet: Topological area that uses the same IP address prefix 147 where that prefix is not further subdivided except into individual 148 addresses as specified from [RFC4903]. 150 Link: Topological area bounded by routers which decrement the IPv4 151 TTL or IPv6 Hop Limit when forwarding the packet as specified from 152 [RFC4903]. 154 Transport Connection: The MAC layer connection in 802.16 between a SS 155 (MS) and BS with a specific QoS attributes. Several types of 156 connections are defined and these include broadcast, unicast and 157 multicast. Each transport connection is uniquely identified by a 16- 158 bit connection identifier (CID). A transport connection is a unique 159 connection intended for user traffic. The scope of the transport 160 connection is between the SS (MS) and the BS. 162 Connection Identifier (CID): A 16-bit value that identifies a 163 connection to equivalent peers in the 802.16 MAC of the SS (MS) and 164 BS. 166 Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS 167 defined in [IEEE802.16]. 169 802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined 170 in [IEEE802.16]. 172 IP CS: The IP specific subpart of the Packet CS defined in 173 [IEEE802.16]. 175 IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 176 (Packet, IPv4) 178 IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 179 (Packet, IPv6). 181 3. Overview of the IEEE 802.16 MAC layer 183 802.16 [IEEE802.16] is point-to-point and connection-oriented at the 184 MAC, physically arranged in a point-to-multipoint structure with the 185 BS terminating one end of each connection and an individual SS 186 terminating the other end of each connection. Each SS in the network 187 possesses a 48-bit MAC address. The BS possesses a 48-bit unique 188 identifier called "BSId". The BS and SS learn each others' MAC 189 Address/BSId during the SS's entry into the network. Additionally, 190 the BS may possess a 48-bit MAC address, but this is only known to 191 the SS if using the Ethernet CS. 193 3.1. Transport Connections 195 User data traffic in both the BS-bound (uplink) and SS-bound 196 (downlink) directions is carried on unidirectional "transport 197 connections". Each transport connection has a particular set of 198 associated parameters indicating characteristics such as 199 cryptographic suite and quality-of-service. 201 After successful entry of a SS to the 802.16 network, no data traffic 202 is possible as there are yet no transport connections between the BS 203 and the SS. Transport connections are established by a 3-message 204 signaling sequence within the MAC layer (usually initiated by the 205 BS). 207 A downlink-direction transport connection is regarded as "multicast" 208 if it has been made available (via MAC signaling) to more than one 209 SS. Uplink-direction connections are always unicast. 211 3.2. 802.16 PDU format 213 An 802.16 PDU (ie. the format that is transmitted over the airlink) 214 consists of a Generic MAC header, various optional subheaders, and a 215 data payload. 217 The 802.16 Generic MAC header carries the Connection Identifier (CID) 218 of the connection with which the PDU is associated. We should 219 observe that there is no source or destination address present in the 220 raw 802.16 MAC header. 222 3.3. 802.16 Convergence Sublayer 224 The 802.16 convergence sublayer (CS) is the component of the MAC that 225 is responsible for mapping between the MAC service and the internal 226 connection oriented service of the MAC CPS (Common Part Sublayer), 227 through classification and encapsulation. The classification process 228 assigns transmit-direction Service Data Units (originating from a 229 higher layer application, e.g., an IP stack at the BS or SS) to a 230 specific outbound transport connection. The convergence sublayer 231 maintains an ordered "classifier table". Each entry in the 232 classifier table includes a classifier and a target CID. A 233 classifier, in turn, consists of a conjunction of one or more 234 subclassifiers - where each subclassifier specifies a packet field 235 (eg. the destination MAC address in an Ethernet frame, or the TOS 236 field of an IP datagram contained in an Ethernet frame) together with 237 a particular value or range of values for the field. To perform 238 classification on an outbound Service Data Unit, the convergence 239 sublayer proceeds from the first entry of the classifier table to the 240 last, and evaluates the fields of the Service Data Unit for a match 241 with the table entry's classifier when a match is found, the 242 convergence sublayer associates the Service Data Unit with the target 243 CID (for eventual transmission), and the remainder of the 802.16 MAC 244 and PHY processing can take place. 246 802.16 defines two convergence sublayer types, the ATM CS and the 247 Packet CS. The ATM CS supports ATM directly. The Packet CS is 248 subdivided into three specific subparts. 250 o "The IP Specific Subpart" carries IP packets over a point-to-point 251 connection. 253 o "The 802.3 Ethernet Specific Subpart" carries packets encoded in 254 the 802.3/Ethernet packet format with 802.3 style headers. 256 o "The 802.1Q VLAN Specific Subpart" carries 802 style packets that 257 contain 802.1Q VLAN Tags. 259 Classifiers applied to connections at the time of connection 260 establishment further classifie and subdivide the nature of the 261 traffic over a connection. 263 The classifications that apply to the Ethernet CS include packet over 264 the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 265 802.3/Ethernet CS, 802.3/Ethernet CS with ROHC header compression and 266 802.3/Ethernet with ECRTP header compression. 268 The classifications that apply to the 802.1Q/VLAN CS include IPv4 269 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN. 271 It should be noted that while the 802.3/Ethernet CS has a packet 272 classification that does not restrict the IP version (packet over the 273 802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP 274 classifiers for those CSs are either IPv4 or IPv6. 276 The classifiers enable the MAC to be sure of the presence of fields 277 in the headers and so to be able to apply the payload header 278 suppression (PHS) feature of 802.16 to those headers. 280 For the sake of brevity in this document, the following naming 281 conventions will be used for particular classifications of particular 282 subparts of particular CSs. 284 o IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, 285 IPv4) 287 o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, 288 IPv6) 290 o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 291 (Packet, 802.3/Ethernet) 293 An implementation of 802.16 can support multiple CS types. 295 We can observe that the CS type, subpart and classification actually 296 defines the type of data interface (eg. IPv4/IPv6 or 802.3) that is 297 presented by 802.16 to the higher layer application. 299 4. IP over IEEE 802.16 Problem Statement and Goals 301 4.1. Root Problem 303 The key issue when deploying IP over IEEE 802.16 network is how to 304 configure an IP Subnet over that link which is connection-oriented 305 and point-to-point in the MAC level. IP Subnet is a topological area 306 that uses the same IP address prefix where that prefix is not further 307 subdivided except into individual addresses. [RFC4903] There are 308 three different IP Subnet models [RFC4968] that are possible for 309 802.16 network: 311 1) Point-to-point Link Model 312 2) Ethernet-like Link Model 314 3) Shared IPv6 Prefix Link Model 316 The specific problems and issues when adopting the above IP Subnet 317 models to the IEEE 802.16 network are as below: 319 In the point-to-point link model, each SS under a BS resides on a 320 different IP Subnet. Therefore, only a certain SS and an AR exist 321 under an IP Subnet, and IP packets with destination address of link 322 local scope are delivered only within the point-to-point link between 323 a SS and an AR. PPP [RFC1661] has been widely used for this kind of 324 point-to-point link. However, the direct use of PPP is not possible 325 on the 802.16 network because 802.16 does not define a convergence 326 sublayer which can encapsulate and decapsulate PPP frames. 327 Therefore, there needs to be a mechanism to provide a point-to-point 328 link between a SS and an AR in case of IP CS. The other alternative 329 is to utilize PPP over Ethernet by using the Ethernet CS. However, 330 Ethernet CS assumes the upper layer's bridging functionality to 331 realize the Ethernet-like link model. 333 In the Ethernet-like link model, all SSs under an AR reside on the 334 same IP Subnet. This also applies when SSs are connected with 335 different BSs. This Ethernet-like link model assumes that underlying 336 link-layer provides the equivalent functionality like Ethernet, for 337 example, native broadcast and multicast. It seems feasible to apply 338 802.16's Ethernet CS to configure this link model. However, 802.16's 339 MAC feature is still connection-oriented, and does not provide 340 multicast and broadcast connection for IP packet transfer. 341 Therefore, we need a mechanism like IEEE 802.1D to realize multicast 342 and broadcast. Moreover, frequent IP multicast and broadcast 343 signaling should be avoided not to wake up sleep/idle [IEEE802.16e] 344 SSs. 346 The shared IPv6 prefix link model eventually results in multi-link 347 subnet problems [RFC4903]. In 802.16, the BS assigns separate 802.16 348 connections for SSs. Therefore, SSs are placed on different links. 349 In this situation, distributing shared IPv6 prefix for SSs which are 350 placed on different links causes multi-link subnet problems. This 351 applies to IP CS and even to Ethernet CS if no bridging functionality 352 is implemented on top of the BS or between the BS and the AR. 354 We identified the feasible IP Subnet models for IEEE 802.16 networks 355 depending on the convergence sublayers. At the current stage, only 356 the IP CS and Ethernet CS of IEEE 802.16 are within the scope of 357 16ng. Following are the feasible IP Subnet models for each 358 convergence sublayer used. 360 1. Point-to-Point Link model for IP CS. 362 2. Ethernet-like Link Model for Ethernet CS. 364 According to the point-to-point feature of the 802.16 MAC, the Point- 365 to-Point link model is the feasible IP Subnet model in the case of IP 366 CS. For the Ethernet CS, the Ethernet-like link model is the 367 feasible IP Subnet model. However, in this model unnecessary 368 multicast and broadcast packets within an IP Subnet should be 369 minimized. 371 4.2. Point-to-Point Link model for IP CS: Problems 373 - Address Resolution: 375 Address Resolution is the process by which IP nodes determine the 376 link-layer address of a destination node on the same IP Subnet given 377 only the destination's IP address. In the case of IPCS, the 802.16 378 MAC address is not used as part of the 802.16 frame so typical usage 379 of the ARP or Neighbor cache does not apply. Thus, performing the 380 address resolution may be redundant in the case of IP CS. For IPv4, 381 ARP cannot be carried by the IP CS, so is not used either by the SS 382 or by the BS. For IPv6, address resolution is the function of IP 383 layer, and IP reachability state is maintained through neighbor 384 discovery packets. Therefore, blocking neighbor discovery packets 385 would break the neighbor unreachability detection model. 387 -Router Discovery: 389 The BS needs to send the RA with separate IP prefix in unicast manner 390 for each SS explicitly to send periodic router advertisements in 391 802.16 Networks. 393 - Prefix Assignment: 395 Separate IP prefix should be distributed for each SS to locate them 396 on different IP Subnets. When a SS moves between BSs under the same 397 AR, the AR needs to redistribute the same IP Subnet prefix which the 398 SS used at the previous BS. 400 - Next-Hop: 402 SS's next-hop always needs to be the AR which provides the IP 403 connectivity at that access network. 405 - Neighbor Unreachability Detection (NUD): 407 Because the SS always sees an AR as the next hop, the NUD is required 408 only for that AR. Also the requirement of NUD may depend on the 409 existence of a connection to the BS for that particular destination. 411 - Address Autoconfiguration: 413 Because a unique prefix is assigned to each SS, the IP Subnet 414 consists of only one SS and an AR. Therefore, duplicate address 415 detection (DAD) is trivial. 417 4.3. Ethernet-like Link model for Ethernet CS: Problems 419 - Address Resolution: 421 For Ethernet CS, the sender needs to perform an address resolution to 422 fill the destination Ethernet address field even though that address 423 is not used for transmitting an 802.16 frame on the air. That 424 Ethernet destination address is used for a BS or bridge to decide 425 where to forward that Ethernet frame after decapsulating the 802.16 426 frame. When the destination's IP address has the same address prefix 427 with its own, the sender should set the Ethernet frame's destination 428 address as the destination itself. To acquire that address, the 429 address resolution should be performed throughout conventional 430 broadcast and multicast based ARP or NDP. However, if not filtered 431 (e.g., [RFC4541]), these multicast and broadcast packets result in 432 the problem of waking up the sleep/idle [IEEE802.16e] SSs. 434 - Router Discovery: 436 All SSs under the AR are located in the same broadcast domain in the 437 Ethernet-like link model. In this environment, sending periodic 438 Router Advertisements with the destination of all-nodes multicast 439 address results in the problem of waking up the sleep/idle 440 [IEEE802.16e] SSs. 442 - Prefix Assignment: 444 Because the same IP prefix is shared with multiple SSs, an IP Subnet 445 consists of multiple SSs and an AR. The SS assumes that there exist 446 on-link neighbors and tries to resolve the L2 address for the on-link 447 prefixes. However, direct communication using link-layer address 448 between two SSs is not possible only with Ethernet CS without adding 449 bridging functionality on top of the BS or between the BS and AR. 451 - Next-Hop: 453 When Ethernet CS is used and the accompanying Ethernet capability 454 emulation is implemented, the next-hop for the destination IP with 455 the same global prefix with the sender or link local address type 456 should be the destination itself not an AR. 458 - Neighbor Unreachability Detection (NUD): 460 All SSs under the same AR are all the neighbors. Therefore, the NUD 461 is required for all the SSs and AR. 463 - Address Autoconfiguration: 465 Duplicate address detection (DAD) should be performed among multiple 466 SSs and an AR which are using the same IP prefix. The previous 467 multicast-based DAD causes the problem of waking up the sleep/idle 468 [IEEE802.16e] SSs. 470 4.4. IP over IEEE 802.16 Goals 472 The following are the goals in no particular order that point at 473 relevant work to be done in IETF. 475 Goal #1. Define the way to provide the point-to-point link model for 476 IP CS. 478 Goal #2. Reduce the power consumption caused by waking up sleep/idle 479 [IEEE802.16e] terminals for Ethernet-like link model. 481 Goal #3. Avoid multilink subnet problems. 483 Goal #4. Allow applicability of security schemes such as SeND 484 [RFC3971]. 486 Goal #5. Do not introduce any new security threats. 488 5. IANA Considerations 490 This document does not require any actions from IANA. 492 6. Security Considerations 494 This documents describes the problem statement and goals for IP over 495 802.16 networks and does not introduce any new security threats. The 496 802.16 link-layer employs cryptographic security mechanisms as 497 specified in [IEEE802.16][IEEE802.16e]. 499 7. Contributors 501 This document is a joint effort of the problem statement team of the 502 16ng WG. The team members include Junghoon Jee, Syam Madanapalli, 503 Jeff Mandin, Gabriel Montenegro, Soohong Daniel Park and Maximilian 504 Riegel. 506 The problem statment team members can be reached at: 508 Junghoon Jee, jhjee@etri.re.kr 510 Syam Madanapalli, smadanapalli@gmail.com 512 Jeff Mandin, jeff@streetwaves-networks.com 514 Gabriel Montenegro, g_e_montenegro@yahoo.com 516 Soohong Daniel Park, soohong.park@samsung.com 518 Maximilian Riegel, maximilian.riegel@nsn.com 520 8. Acknowledgment 522 The authors would like to express special thank to David Johnston for 523 his help with section 4, "Overview of the IEEE 802.16 MAC layer", and 524 for carefully reviewing the entire document, and also to Phil Roberts 525 for suggesting the reorganization of the document depending on the 526 baseline IP subnet models. 528 The authors also would like to thank Jari Arkko, HeeYoung Jung, 529 Myung-Ki Shin, Eun-Kyoung Paik, Jaesun Cha and KWISF (Korea Wireless 530 Internet Standardization Forum) for their comments and contributions. 532 9. References 534 9.1. Normative References 536 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 537 RFC 1661, July 1994. 539 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 540 Neighbor Discovery (SEND)", RFC 3971, March 2005. 542 9.2. Informative References 544 [IEEE802.16] 545 IEEE Std 802.16-2004, "IEEE Standard for Local and 546 metropolitan area networks, Part 16: Air Interface for 547 Fixed Broadband Wireless Access Systems", October 2004. 549 [IEEE802.16e] 550 IEEE Std 802.16e, "IEEE standard for Local and 551 metropolitan area networks, Part 16:Air Interface for 552 fixed and Mobile broadband wireless access systems", 553 October 2005. 555 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 556 "Considerations for Internet Group Management Protocol 557 (IGMP) and Multicast Listener Discovery (MLD) Snooping 558 Switches", RFC 4541, May 2006. 560 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 561 June 2007. 563 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 564 Based Networks", RFC 4968, August 2007. 566 Authors' Addresses 568 Junghoon Jee 569 ETRI 570 161 Gajeong-dong Yuseong-gu 571 Daejeon 305-350 572 Korea 574 Email: jhjee@etri.re.kr 576 Syam Madanapalli 577 Ordyn Technologies 579 Email: smadanapalli@gmail.com 581 Jeff Mandin 582 Runcom 584 Email: jeff@streetwaves-networks.com 586 Full Copyright Statement 588 Copyright (C) The IETF Trust (2007). 590 This document is subject to the rights, licenses and restrictions 591 contained in BCP 78, and except as set forth therein, the authors 592 retain all their rights. 594 This document and the information contained herein are provided on an 595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 597 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 598 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 599 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Intellectual Property 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Acknowledgment 628 Funding for the RFC Editor function is provided by the IETF 629 Administrative Support Activity (IASA).