idnits 2.17.1 draft-ietf-16ng-ps-goals-02.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 632. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 59 lines 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 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 (August 13, 2007) is 6101 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: 1 error (**), 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. Jee, Editor 3 Internet-Draft ETRI 4 Intended status: Standards Track S. Madanapalli 5 Expires: February 14, 2008 LogicaCMG 6 J. Mandin 7 Runcom 8 G. Montenegro 9 Microsoft 10 S. Park 11 Samsung Electronics 12 M. Riegel 13 NSN 14 August 13, 2007 16 IP over 802.16 Problem Statement and Goals 17 draft-ietf-16ng-ps-goals-02.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on February 14, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 This document specifies problems in running the IETF IP protocols 51 over IEEE 802.16 networks by identifying specific gaps in the 802.16 52 MAC for IPv4 and IPv6 support. This document also provides an 53 overview of IEEE 802.16 network characteristics and convergence 54 sublayers. The common terminology to be used for the base guideline 55 while defining the solution frameworks is also presented. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 5 63 4.1. Transport Connections . . . . . . . . . . . . . . . . . . 5 64 4.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 6 65 4.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 6 66 5. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 7 67 5.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. Point-to-Point Link model for IP CS: Problems . . . . . . 9 69 5.3. Ethernet like Link model for Ethernet CS: Problems . . . . 10 70 5.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 11 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 Intellectual Property and Copyright Statements . . . . . . . . . . 14 80 1. Introduction 82 Broadband Wireless Access networks address the inadequacies of low 83 bandwidth wireless communication for user requirements such as high 84 quality data/voice service, fast mobility, wide coverage, etc. The 85 IEEE 802.16 Working Group on Broadband Wireless Access Standards 86 develops standards and recommended practices to support the 87 development and deployment of broadband Wireless Metropolitan Area 88 Networks [IEEE802.16]. 90 Recently, the WiMAX Forum, and, in particular, its NWG (Network 91 Working Group) is defining the IEEE 802.16 network architecture 92 (e.g., IPv4, IPv6, Mobility, Interworking with different networks, 93 AAA, etc). The NWG is thus taking on work at layers above those 94 defined by the IEEE 802 standards (typically limited to the physical 95 and link layers only). Similarly, WiBro (Wireless Broadband), a 96 Korean effort which focuses on the 2.3 GHz spectrum band, is also 97 based on the IEEE 802.16 specification [IEEE802.16]. 99 802.16 [IEEE802.16] is point-to-point and connection-oriented at the 100 MAC, physically arranged in a point-to-multipoint structure with the 101 BS terminating one end of each connection and an individual SS 102 terminating the other end of each connection. The 802.16 convergence 103 sublayer (CS) is at the uppermost of the MAC that is responsible for 104 assigning transmit-direction SDUs (originating from a higher layer 105 application - eg. an IP or Ethernet at the BS or SS) to a specific 106 outbound transport connection. 802.16 defines two convergence 107 sublayer types, the ATM CS and the Packet CS. The IP Specific 108 Subpart (IP CS) and the 802.3 Ethernet Specific Subpart (Ethernet CS) 109 of Packet CS is within the current 16ng WG scope. 111 There exists complexity in configuring the IP Subnet over IEEE 802.16 112 network because of its point-to-point connection oriented feature and 113 the existence of IP CS and Ethernet CS which assume different higher 114 layer functionality. IP Subnet is a topological area that uses the 115 same IP address prefix where that prefix is not further subdivided 116 except into individual addresses as specified from 117 [I-D.thaler-intarea-multilink-subnet-issues]. The IP Subnet 118 configuration is dependent on the underlying link layer's 119 characteristic and decides the overall IP operation on the network. 120 The IP CS and Ethernet CS of IEEE 802.16 assume different higher 121 layer capability, like the IP routing functionality in case of IP CS 122 and the bridging functionality in case of Ethernet CS. This means 123 that underlying link layer's characteristics beneath IP can change 124 according to the adopted convergence sublayers. 126 This document provides the feasible IP Subnet model for each IP CS 127 and Ethernet CS and specifies the problems in running IP protocols 128 for each case. This document also presents an overview of 802.16 129 network characteristics specifically focusing on the convergence 130 sublayers and the common terminology to be used for the base 131 guideline while defining solution frameworks. 133 2. Requirements 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119] . 139 3. Terminology 141 Subscriber Station (SS): An end-user equipment that provides 142 connectivity to the 802.16 networks. It can be either fixed/nomadic 143 or mobile equipment. In mobile environment, SS represents the Mobile 144 Subscriber Station (MS) introduced in [IEEE802.16e]. 146 Base Station (BS): A generalized equipment sets providing 147 connectivity, management, and control between the subscriber station 148 and the 802.16 networks. 150 Access Router (AR): An entity that performs an IP routing function to 151 provide IP connectivity for subscriber station (SS or MS). 153 Protocol Data Unit (PDU): This refers to the data format passed from 154 the lower edge of the 802.16 MAC to the 802.16 PHY, which typically 155 contains SDU data after fragmentation, encryption, etc. 157 Service Data Unit (SDU): This refers to the data format passed to the 158 upper edge of the 802.16 MAC 160 IP Subnet: Topological area that uses the same IP address prefix 161 where that prefix is not further subdivided except into individual 162 addresses as specified from 163 [I-D.thaler-intarea-multilink-subnet-issues]. 165 Link: Topological area bounded by routers which decrement the IPv4 166 TTL or IPv6 Hop Limit when forwarding the packet as specified from 167 [I-D.thaler-intarea-multilink-subnet-issues]. 169 Transport Connection: The MAC layer connection in 802.16 between a 170 SS(MS) and BS with a specific QoS attributes. Several types of 171 connections are defined and these include broadcast, unicast and 172 multicast. Each transport connection is uniquely identified by a 16- 173 bit connection identifier (CID). A transport connection is a unique 174 connection intended for user traffic. The scope of the transport 175 connection is between the SS(MS) and the BS. 177 Connection Identifier (CID): A 16-bit value that identifies a 178 connection to equivalent peers in the 802.16 MAC of the SS(MS) and 179 BS. 181 Ethernet CS: It means 802.3/Ethernet CS specific part of the Packet 182 CS defined in 802.16 STD. 184 802.1Q CS: It means 802.1Q (VLAN) specific part of the Packet CS 185 defined in 802.16 STD. 187 IP CS: It means IP specific subpart of the Packet CS defined in 188 802.16 STD. 190 IPv4 CS: It means IP specific subpart of the Packet CS, Classifier 1 191 (Packet, IPv4) 193 IPv6 CS: It means IP specific subpart of the Packet CS, Classifier 2 194 (Packet, IPv6). 196 4. Overview of the IEEE 802.16-2004 MAC layer 198 802.16 [IEEE802.16] is point-to-point and connection-oriented at the 199 MAC, physically arranged in a point-to-multipoint structure with the 200 BS terminating one end of each connection and an individual SS 201 terminating the other end of each connection. Each node in the 202 network possesses a 48-bit MAC address (though in the Base Station 203 this 48-bit unique identifier is called "BSId"). The BS and SS learn 204 each others' MAC Address/BSId during the SS's entry into the network. 206 4.1. Transport Connections 208 User data traffic in both the BS-bound (uplink) and SS-bound 209 (downlink) directions is carried on unidirectional "transport 210 connections". Each transport connection has a particular set of 211 associated parameters indicating characteristics such as 212 cryptographic suite and quality-of-service. 214 After successful entry of a SS to the 802.16 network, no data traffic 215 is possible - as there are as yet no transport connections between 216 the BS and SS. Transport connections are established by a 3-message 217 signaling sequence within the MAC layer (usually initiated by the 218 BS). 220 A downlink-direction transport connection is regarded as "multicast" 221 if it has been made available (via MAC signaling) to more than one 222 SS. Uplink-direction connections are always unicast. 224 4.2. 802.16 PDU format 226 An 802.16 PDU (ie. the format that is transmitted over the airlink) 227 consists of a Generic MAC header, various optional subheaders, and a 228 data payload. 230 The 802.16 Generic MAC header carries the Connection Identifier (CID) 231 of the connection with which the PDU is associated. We should 232 observe that there is no source or destination address present in the 233 raw 802.16 MAC header. 235 4.3. 802.16 Convergence Sublayer 237 The 802.16 convergence sublayer (CS) is the component of the MAC that 238 is responsible for mapping between the MAC service and the internal 239 connection oriented service of the MAC CPS (Common Part Sublayer), 240 through classification and encapsulation. The classification process 241 assigns transmit-direction SDUs (originating from a higher layer 242 application - eg. an IP stack at the BS or SS) to a specific outbound 243 transport connection. The convergence sublayer maintains an ordered 244 "classifier table". Each entry in the classifier table includes a 245 classifier and a target CID. A classifier, in turn, consists of a 246 conjunction of one or more subclassifiers - where each subclassifier 247 specifies a packet field (eg. the destination MAC address in an 248 Ethernet frame, or the TOS field of an IP datagram contained in an 249 Ethernet frame) together with a particular value or range of values 250 for the field. To perform classification on an outbound SDU, the 251 convergence sublayer proceeds from the first entry of the classifier 252 table to the last, and evaluates the fields of the SDU for a match 253 with the table entry's classifier when a match is found, the 254 convergence sublayer associates the SDU with the target CID (for 255 eventual transmission), and the remainder of the 802.16 MAC and PHY 256 processing can take place. 258 802.16 defines two convergence sublayer types, the ATM CS and the 259 Packet CS. The ATM CS supports ATM directly. The Packet CS is 260 subdivided into three specific subparts. 262 o "The IP Specific Subpart" carries IP packets over a point-to-point 263 connection. 265 o "The 802.3 Ethernet Specific Subpart" carries packets encoded in 266 the 802.3/Ethernet packet format with 802.3 style headers. 268 o "The 802.1Q VLAN Specific Subpart" carries 802 style packets that 269 contain 802.1Q VLAN Tags. 271 Classifiers applied to connections at the time of connection 272 establishment further classifies and subdivides the nature of the 273 traffic over a connection. 275 The classifications that apply to the Ethernet CS include packet over 276 the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 277 802.3/Ethernet CS, 802.3/Ethernet CS with ROHC header compression and 278 802.3/Ethernet with ECRTP header compression. 280 The classifications that apply to the 802.1Q/VLAN CS include IPv4 281 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN. 283 It should be noted that while the 802.3/Ethernet CS has a packet 284 classification that does not restrict the IP version (packet over the 285 802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP 286 classifiers for those CSs are either IPv4 or IPv6. 288 The classifiers enable the MAC to be sure of the presence of fields 289 in the headers and so to be able to apply the payload header 290 suppression (PHS) feature of 802.16 to those headers. 292 For the sake of brevity in this document, the following naming 293 conventions will be used for particular classifications of particular 294 subparts of particular CSs. 296 o IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, 297 IPv4) 299 o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, 300 IPv6) 302 o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 303 (Packet, 802.3/Ethernet) 305 An implementation of 802.16 can support multiple CS types. 307 We can observe that the CS type, subpart and classification actually 308 defines the type of data interface (eg. IPv4/IPv6 or 802.3) that is 309 presented by 802.16 to the higher layer application. 311 5. IP over IEEE 802.16 Problem Statement and Goals 312 5.1. Root Problem 314 The key issue when deploying IP over IEEE 802.16 network is how to 315 configure an IP Subnet over that link which is connection-oriented 316 and point-to-point in the MAC level. IP Subnet is a topological area 317 that uses the same IP address prefix where that prefix is not further 318 subdivided except into individual addresses. 319 [I-D.thaler-intarea-multilink-subnet-issues] There are three 320 different IP Subnet models [RFC4968] that are possible for 802.16 321 network: 323 1) Point-to-point Link Model 325 2) Ethernet like Link Model 327 3) Shared IPv6 Prefix Link Model 329 The specific problems and issues when adopting the above IP Subnet 330 models to the IEEE 802.16 network are like below: 332 In the first point-to-point link model, each SS under a BS resides on 333 the different IP Subnets. Therefore, only a certain SS and an AR 334 exist under an IP Subnet and IP packets with destination address of 335 link local scope are delivered only within the point-to-point link 336 between a SS and an AR. The PPP [RFC1661] has been widely used for 337 this kind of point-to-point link. However, the direct use of PPP is 338 not possible on the 802.16 network because the 802.16 does not define 339 a convergence sublayer which can encapsulate and decapsulate PPP 340 frames. Therefore, there needs to be a mechanism to provide a point- 341 to-point link between a SS and an AR in case of IP CS. The other 342 alternative is to utilize the PPP over Ethernet by using the Ethernet 343 CS. However, Ethernet CS assumes the upper layer's bridging 344 functionality to realize the Ethernet like link model. 346 In the second Ethernet like link model, all SSs under an AR reside on 347 the same IP Subnet. This also applies when SSs are connected with 348 different BSs. This Ethernet like link model assumes that underlying 349 link layer provides the equivalent functionality like Ethernet, for 350 example, native broadcast and multicast. It seems feasible to apply 351 the 802.16's Ethernet CS to configure this link model. However, 352 there exists a discrepancy between the assumption from the Ethernet 353 like link model and the 802.16's MAC feature which is connection- 354 oriented and not providing multicast and broadcast connection for IP 355 packet transfer. Moreover, the frequent IP multicast and broadcast 356 signaling within the IP subnet like Ethernet results in the problem 357 of waking up sleep/idle [IEEE802.16e] SSs. 359 The last shared IPv6 prefix link model eventually results in multi- 360 link subnet problems [I-D.thaler-intarea-multilink-subnet-issues]. 361 In 802.16, BS assigns separate 802.16 connections for SSs. 362 Therefore, SSs are placed on the different links. In this situation, 363 distributing shared IPv6 prefix for SSs which are placed on the 364 different links causes the multi-link subnet problems. This is valid 365 for IP CS and even to the Ethernet CS if any bridging functionality 366 is not implemented on top of BS or between BS and AR. 368 We identified the feasible IP Subnet models for IEEE 802.16 networks 369 depending on the convergence sublayers. At the current stage, only 370 the IP CS and Ethernet CS of IEEE 802.16 are within the 16ng scope. 371 Followings are the feasible IP Subnet models for each convergence 372 sublayer used. 374 1. Point-to-Point Link model for IP CS. 376 2. Ethernet like Link Model for Ethernet CS. 378 According to the point-to-point feature of 802.16's MAC, the Point- 379 to-Point link model is the feasible IP Subnet model for IP CS under 380 considering the multilink subnet problems. For the Ethernet CS, the 381 Ethernet like link model is the feasible IP Subnet model. However, 382 in this model unnecessary multicast and broadcast packets within an 383 IP Subnet should be minimized. 385 5.2. Point-to-Point Link model for IP CS: Problems 387 - Address Resolution: 389 Address Resolution is the process by which IP nodes determine the 390 link- layer address of a destination node on the same IP Subnet given 391 only the destination's IP address. In IP CS case, however, there is 392 no need for address resolution because ARP cache or Neighbor cache as 393 802.16 MAC address is never used as part of the 802.16 frame. 394 Blocking ARP or the address resolution of NDP needs to be implemented 395 by SS itself in an implementation manner. 397 -Router Discovery: 399 Because MAC address is not used for transmission in case of IP CS, it 400 is unclear whether source link layer address need to be carried in 401 the RS (Router Solicitation). The RS may need to have source IP 402 address specified so that the RA (Router Advertisement) can be sent 403 back. This may require the completion of the link local address 404 configuration before sending an RS. For sending periodic router 405 advertisements in 802.16 Networks, BS needs to send the RA with 406 separate IP prefix in unicast manner for each SS explicitly. 408 - Prefix Assignment: 410 Separate IP prefix should be distributed for each SS to locate them 411 on different IP Subnets. When a SS moves between BSs under the same 412 AR, the AR needs to redistribute the same IP Subnet prefix which the 413 SS used at the previous BS. 415 - Next-Hop: 417 SS's next-hop always needs to be the AR which provides the IP 418 connectivity at that access network. 420 - Neighbor Unreachability Detection (NUD): 422 Because SS always see an AR as the next hop, the NUD is required only 423 for that AR. Also the requirement of NUD may depend on the existence 424 of a connection to the BS for that particular destination. If there 425 exists multiple ARs (so the default routers), it is unknown if the 426 NUD is required if an AR is not serving any 802.16 MAC connection. 428 - Address Autoconfiguration: 430 Because a unique prefix is assigned to each SS, the IP Subnet 431 consists of only one SS and an AR. Therefore, duplicate address 432 detection (DAD) is trivial. 434 5.3. Ethernet like Link model for Ethernet CS: Problems 436 - Address Resolution: 438 For Ethernet CS, sender needs to perform an address resolution to 439 fill the destination Ethernet address field even though that address 440 is not used for transmitting an 802.16 frame on the air. That 441 Ethernet destination address is used for a BS or bridge to decide 442 where to forward that Ethernet frame after decapsulating the 802.16 443 frame. When the destination's IP address has the same address prefix 444 with its own, the sender should set the Ethernet frame's destination 445 address as the destination itself. To acquire that address, the 446 address resolution should be performed throughout conventional 447 broadcast and multicast based ARP or NDP. However, this multicast 448 and broadcast packets results in the problem of waking up the sleep/ 449 idle [IEEE802.16e] SSs. 451 - Router Discovery: 453 All SSs under the AR are located in the same broadcast domain in the 454 Ethernet like link model. In this environment, sending periodic 455 Router Advertisements with the destination of all-nodes multicast 456 address results in the problem of waking up the sleep/idle 457 [IEEE802.16e] SSs. 459 - Prefix Assignment: 461 Because the same IP prefix is shared with multiple SSs, an IP Subnet 462 consists of multiple SSs and an AR. SS assumes that there exist on- 463 link neighbors and tries to resolve the L2 address for the on-link 464 prefixes. However, direct communication using link layer address 465 between two SSs is not possible only with Ethernet CS without adding 466 bridging functionality on top of BS or between BS and AR. 468 - Next-Hop: 470 When Ethernet CS is used and the accompanying Ethernet capability 471 emulation is implemented, the next-hop for the destination IP with 472 the same global prefix with the sender or link local address type 473 should be the destination itself not an AR. 475 - Neighbor Unreachability Detection (NUD): 477 All SSs under the same AR are all the neighbors. Therefore, the NUD 478 is required for all the SSs and AR. 480 - Address Autoconfiguration: 482 The duplicate address detection (DAD) should be performed among 483 multiple SSs and an AR which are using the same IP prefix. The 484 previous multicast based DAD cause the problem of waking up the 485 sleep/idle [IEEE802.16e] SSs. 487 5.4. IP over IEEE 802.16 Goals 489 The following are the goals in no particular order that point at 490 relevant work to be done in IETF. 492 Goal #1. Define the way to provide the point-to-point link model for 493 IP CS. 495 Goal #2. Reduce the power consumption caused by waking up sleep/idle 496 [IEEE802.16e] terminals for Ethernet like link model. 498 Goal #3. Do not cause multilink subnet problems. 500 Goal #4. Provide the applicability of the previous security works 501 like SEND [RFC3971]. 503 Goal #5. Do not introduce any new security threats. 505 6. IANA Considerations 507 This document does not require any actions from IANA. 509 7. Security Considerations 511 This documents describes the problem statement and goals for IP over 512 802.16 networks and does not introduce any new security threats. 514 8. Acknowledgment 516 The authors would like to express special thank to David Johnston for 517 amending the section 4, "Overview of the IEEE 802.16-2006 MAC layer" 518 and carefully reviewing the entire document and also to Phil Roberts 519 for suggesting the reorganization of the document depending on the 520 baseline IP subnet models. 522 The authors also would like to express thank to IETF Mobility Working 523 Group members of KWISF (Korea Wireless Internet Standardization 524 Forum) and HeeYoung Jung for for their initial efforts as well as 525 Myung-Ki Shin, Eun-Kyoung Paik and Jaesun Cha for their contribution 526 to previous works. 528 9. References 530 9.1. Normative References 532 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 533 RFC 1661, July 1994. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 539 Neighbor Discovery (SEND)", RFC 3971, March 2005. 541 9.2. Informative References 543 [I-D.thaler-intarea-multilink-subnet-issues] 544 Thaler, D., "Issues With Protocols Proposing Multilink 545 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 546 (work in progress), March 2006. 548 [IEEE802.16] 549 IEEE Std 802.16-2004, "IEEE Standard for Local and 550 metropolitan area networks, Part 16: Air Interface for 551 Fixed Broadband Wireless Access Systems", October 2004. 553 [IEEE802.16e] 554 IEEE Std 802.16e, "IEEE standard for Local and 555 metropolitan area networks, Part 16:Air Interface for 556 fixed and Mobile broadband wireless access systems", 557 October 2005. 559 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 560 Based Networks", RFC 4968, August 2007. 562 Authors' Addresses 564 Junghoon Jee 565 ETRI 567 Email: jhjee@etri.re.kr 569 Syam Madanapalli 570 LogicaCMG 572 Email: smadanapalli@gmail.com 574 Jeff Mandin 575 Runcom 577 Email: jeff@streetwaves-networks.com 579 gabriel_montenegro_2000@yahoo.com 580 Microsoft 582 Email: gabriel_montenegro_2000@yahoo.com 584 Soohong Daniel Park 585 Samsung Electronics 587 Email: soohong.park@samsung.com 589 Max Riegel 590 Nokia Siemens Networks 592 Email: maximilian.riegel@nsn.com 594 Full Copyright Statement 596 Copyright (C) The IETF Trust (2007). 598 This document is subject to the rights, licenses and restrictions 599 contained in BCP 78, and except as set forth therein, the authors 600 retain all their rights. 602 This document and the information contained herein are provided on an 603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 605 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 606 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 607 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Intellectual Property 612 The IETF takes no position regarding the validity or scope of any 613 Intellectual Property Rights or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; nor does it represent that it has 617 made any independent effort to identify any such rights. Information 618 on the procedures with respect to rights in RFC documents can be 619 found in BCP 78 and BCP 79. 621 Copies of IPR disclosures made to the IETF Secretariat and any 622 assurances of licenses to be made available, or the result of an 623 attempt made to obtain a general license or permission for the use of 624 such proprietary rights by implementers or users of this 625 specification can be obtained from the IETF on-line IPR repository at 626 http://www.ietf.org/ipr. 628 The IETF invites any interested party to bring to its attention any 629 copyrights, patents or patent applications, or other proprietary 630 rights that may cover technology that may be required to implement 631 this standard. Please address the information to the IETF at 632 ietf-ipr@ietf.org. 634 Acknowledgment 636 Funding for the RFC Editor function is provided by the IETF 637 Administrative Support Activity (IASA).