idnits 2.17.1 draft-ietf-16ng-ps-goals-03.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 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 620. 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 (November 18, 2007) is 5997 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. -------------------------------------------------------------------------------- 2 16ng Working Group J. Jee, Editor 3 Internet-Draft ETRI 4 Intended status: Informational S. Madanapalli 5 Expires: May 21, 2008 LogicaCMG 6 J. Mandin 7 Runcom 8 G. Montenegro 9 Microsoft 10 S. Park 11 Samsung Electronics 12 M. Riegel 13 NSN 14 November 18, 2007 16 IP over 802.16 Problem Statement and Goals 17 draft-ietf-16ng-ps-goals-03.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 May 21, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview of the IEEE 802.16-2004 MAC layer . . . . . . . . . . 5 62 3.1. Transport Connections . . . . . . . . . . . . . . . . . . 5 63 3.2. 802.16 PDU format . . . . . . . . . . . . . . . . . . . . 5 64 3.3. 802.16 Convergence Sublayer . . . . . . . . . . . . . . . 6 65 4. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 7 66 4.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.2. Point-to-Point Link model for IP CS: Problems . . . . . . 9 68 4.3. Ethernet like Link model for Ethernet CS: Problems . . . . 10 69 4.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Intellectual Property and Copyright Statements . . . . . . . . . . 14 79 1. Introduction 81 Broadband Wireless Access networks address the inadequacies of low 82 bandwidth wireless communication for user requirements such as high 83 quality data/voice service, fast mobility, wide coverage, etc. The 84 IEEE 802.16 Working Group on Broadband Wireless Access Standards 85 develops standards and recommended practices to support the 86 development and deployment of broadband Wireless Metropolitan Area 87 Networks [IEEE802.16]. 89 Recently, the WiMAX Forum, and, in particular, its NWG (Network 90 Working Group) is defining the IEEE 802.16 network architecture 91 (e.g., IPv4, IPv6, Mobility, Interworking with different networks, 92 AAA, etc). The NWG is thus taking on work at layers above those 93 defined by the IEEE 802 standards (typically limited to the physical 94 and link layers only). Similarly, WiBro (Wireless Broadband), a 95 Korean effort which focuses on the 2.3 GHz spectrum band, is also 96 based on the IEEE 802.16 specification [IEEE802.16]. 98 802.16 [IEEE802.16] is point-to-point and connection-oriented at the 99 MAC, physically arranged in a point-to-multipoint structure with the 100 BS terminating one end of each connection and an individual SS 101 terminating the other end of each connection. The 802.16 convergence 102 sublayer (CS) is at the uppermost part of the MAC that is responsible 103 for assigning transmit-direction Service Data Units (originating from 104 a higher layer application - eg. an IP or Ethernet at the BS or SS) 105 to a specific outbound transport connection. 802.16 defines two 106 convergence sublayer types, the ATM CS and the Packet CS. The IP 107 Specific Subpart (IP CS) and the 802.3 Ethernet Specific Subpart 108 (Ethernet CS) of Packet CS is within the current 16ng WG scope. 110 There exists complexity in configuring the IP Subnet over IEEE 802.16 111 network because of its point-to-point connection oriented feature and 112 the existence of IP CS and Ethernet CS which assume different higher 113 layer functionality. IP Subnet is a topological area that uses the 114 same IP address prefix where that prefix is not further subdivided 115 except into individual addresses as specified from [RFC4903]. The IP 116 Subnet configuration is dependent on the underlying link layer's 117 characteristic and decides the overall IP operation on the network. 118 The IP CS and Ethernet CS of IEEE 802.16 assume different higher 119 layer capability, like the IP routing functionality in case of IP CS 120 and the bridging functionality in case of Ethernet CS. This means 121 that underlying link layer's characteristics beneath IP can change 122 according to the adopted convergence sublayers. 124 This document provides the feasible IP Subnet model for each IP CS 125 and Ethernet CS and specifies the problems in running IP protocols 126 for each case. This document also presents an overview of 802.16 127 network characteristics specifically focusing on the convergence 128 sublayers and the common terminology to be used for the base 129 guideline while defining solution frameworks. 131 2. Terminology 133 Subscriber Station (SS): An end-user equipment that provides 134 connectivity to the 802.16 networks. It can be either fixed/nomadic 135 or mobile equipment. In mobile environment, SS represents the Mobile 136 Subscriber Station (MS) introduced in [IEEE802.16e]. 138 Base Station (BS): A generalized equipment sets providing 139 connectivity, management, and control between the subscriber station 140 and the 802.16 networks. 142 Access Router (AR): An entity that performs an IP routing function to 143 provide IP connectivity for subscriber station (SS or MS). 145 Protocol Data Unit (PDU): This refers to the data format passed from 146 the lower edge of the 802.16 MAC to the 802.16 PHY, which typically 147 contains Service Data Unit data after fragmentation, encryption, etc. 149 Service Data Unit (SDU): This refers to the data format passed to the 150 upper edge of the 802.16 MAC 152 IP Subnet: Topological area that uses the same IP address prefix 153 where that prefix is not further subdivided except into individual 154 addresses as specified from [RFC4903]. 156 Link: Topological area bounded by routers which decrement the IPv4 157 TTL or IPv6 Hop Limit when forwarding the packet as specified from 158 [RFC4903]. 160 Transport Connection: The MAC layer connection in 802.16 between a 161 SS(MS) and BS with a specific QoS attributes. Several types of 162 connections are defined and these include broadcast, unicast and 163 multicast. Each transport connection is uniquely identified by a 16- 164 bit connection identifier (CID). A transport connection is a unique 165 connection intended for user traffic. The scope of the transport 166 connection is between the SS(MS) and the BS. 168 Connection Identifier (CID): A 16-bit value that identifies a 169 connection to equivalent peers in the 802.16 MAC of the SS(MS) and 170 BS. 172 Ethernet CS: It means 802.3/Ethernet CS specific part of the Packet 173 CS defined in 802.16 STD. 175 802.1Q CS: It means 802.1Q (VLAN) specific part of the Packet CS 176 defined in 802.16 STD. 178 IP CS: It means IP specific subpart of the Packet CS defined in 179 802.16 STD. 181 IPv4 CS: It means IP specific subpart of the Packet CS, Classifier 1 182 (Packet, IPv4) 184 IPv6 CS: It means IP specific subpart of the Packet CS, Classifier 2 185 (Packet, IPv6). 187 3. Overview of the IEEE 802.16-2004 MAC layer 189 802.16 [IEEE802.16] is point-to-point and connection-oriented at the 190 MAC, physically arranged in a point-to-multipoint structure with the 191 BS terminating one end of each connection and an individual SS 192 terminating the other end of each connection. Each node in the 193 network possesses a 48-bit MAC address (though in the Base Station 194 this 48-bit unique identifier is called "BSId"). The BS and SS learn 195 each others' MAC Address/BSId during the SS's entry into the network. 197 3.1. Transport Connections 199 User data traffic in both the BS-bound (uplink) and SS-bound 200 (downlink) directions is carried on unidirectional "transport 201 connections". Each transport connection has a particular set of 202 associated parameters indicating characteristics such as 203 cryptographic suite and quality-of-service. 205 After successful entry of a SS to the 802.16 network, no data traffic 206 is possible - as there are as yet no transport connections between 207 the BS and SS. Transport connections are established by a 3-message 208 signaling sequence within the MAC layer (usually initiated by the 209 BS). 211 A downlink-direction transport connection is regarded as "multicast" 212 if it has been made available (via MAC signaling) to more than one 213 SS. Uplink-direction connections are always unicast. 215 3.2. 802.16 PDU format 217 An 802.16 PDU (ie. the format that is transmitted over the airlink) 218 consists of a Generic MAC header, various optional subheaders, and a 219 data payload. 221 The 802.16 Generic MAC header carries the Connection Identifier (CID) 222 of the connection with which the PDU is associated. We should 223 observe that there is no source or destination address present in the 224 raw 802.16 MAC header. 226 3.3. 802.16 Convergence Sublayer 228 The 802.16 convergence sublayer (CS) is the component of the MAC that 229 is responsible for mapping between the MAC service and the internal 230 connection oriented service of the MAC CPS (Common Part Sublayer), 231 through classification and encapsulation. The classification process 232 assigns transmit-direction Service Data Units (originating from a 233 higher layer application - eg. an IP stack at the BS or SS) to a 234 specific outbound transport connection. The convergence sublayer 235 maintains an ordered "classifier table". Each entry in the 236 classifier table includes a classifier and a target CID. A 237 classifier, in turn, consists of a conjunction of one or more 238 subclassifiers - where each subclassifier specifies a packet field 239 (eg. the destination MAC address in an Ethernet frame, or the TOS 240 field of an IP datagram contained in an Ethernet frame) together with 241 a particular value or range of values for the field. To perform 242 classification on an outbound Service Data Unit, the convergence 243 sublayer proceeds from the first entry of the classifier table to the 244 last, and evaluates the fields of the Service Data Unit for a match 245 with the table entry's classifier when a match is found, the 246 convergence sublayer associates the Service Data Unit with the target 247 CID (for eventual transmission), and the remainder of the 802.16 MAC 248 and PHY processing can take place. 250 802.16 defines two convergence sublayer types, the ATM CS and the 251 Packet CS. The ATM CS supports ATM directly. The Packet CS is 252 subdivided into three specific subparts. 254 o "The IP Specific Subpart" carries IP packets over a point-to-point 255 connection. 257 o "The 802.3 Ethernet Specific Subpart" carries packets encoded in 258 the 802.3/Ethernet packet format with 802.3 style headers. 260 o "The 802.1Q VLAN Specific Subpart" carries 802 style packets that 261 contain 802.1Q VLAN Tags. 263 Classifiers applied to connections at the time of connection 264 establishment further classifies and subdivides the nature of the 265 traffic over a connection. 267 The classifications that apply to the Ethernet CS include packet over 268 the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 269 802.3/Ethernet CS, 802.3/Ethernet CS with ROHC header compression and 270 802.3/Ethernet with ECRTP header compression. 272 The classifications that apply to the 802.1Q/VLAN CS include IPv4 273 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN. 275 It should be noted that while the 802.3/Ethernet CS has a packet 276 classification that does not restrict the IP version (packet over the 277 802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP 278 classifiers for those CSs are either IPv4 or IPv6. 280 The classifiers enable the MAC to be sure of the presence of fields 281 in the headers and so to be able to apply the payload header 282 suppression (PHS) feature of 802.16 to those headers. 284 For the sake of brevity in this document, the following naming 285 conventions will be used for particular classifications of particular 286 subparts of particular CSs. 288 o IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, 289 IPv4) 291 o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, 292 IPv6) 294 o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 295 (Packet, 802.3/Ethernet) 297 An implementation of 802.16 can support multiple CS types. 299 We can observe that the CS type, subpart and classification actually 300 defines the type of data interface (eg. IPv4/IPv6 or 802.3) that is 301 presented by 802.16 to the higher layer application. 303 4. IP over IEEE 802.16 Problem Statement and Goals 305 4.1. Root Problem 307 The key issue when deploying IP over IEEE 802.16 network is how to 308 configure an IP Subnet over that link which is connection-oriented 309 and point-to-point in the MAC level. IP Subnet is a topological area 310 that uses the same IP address prefix where that prefix is not further 311 subdivided except into individual addresses. [RFC4903] There are 312 three different IP Subnet models [RFC4968] that are possible for 313 802.16 network: 315 1) Point-to-point Link Model 316 2) Ethernet like Link Model 318 3) Shared IPv6 Prefix Link Model 320 The specific problems and issues when adopting the above IP Subnet 321 models to the IEEE 802.16 network are like below: 323 In the first point-to-point link model, each SS under a BS resides on 324 the different IP Subnets. Therefore, only a certain SS and an AR 325 exist under an IP Subnet and IP packets with destination address of 326 link local scope are delivered only within the point-to-point link 327 between a SS and an AR. The PPP [RFC1661] has been widely used for 328 this kind of point-to-point link. However, the direct use of PPP is 329 not possible on the 802.16 network because the 802.16 does not define 330 a convergence sublayer which can encapsulate and decapsulate PPP 331 frames. Therefore, there needs to be a mechanism to provide a point- 332 to-point link between a SS and an AR in case of IP CS. The other 333 alternative is to utilize the PPP over Ethernet by using the Ethernet 334 CS. However, Ethernet CS assumes the upper layer's bridging 335 functionality to realize the Ethernet like link model. 337 In the second Ethernet like link model, all SSs under an AR reside on 338 the same IP Subnet. This also applies when SSs are connected with 339 different BSs. This Ethernet like link model assumes that underlying 340 link layer provides the equivalent functionality like Ethernet, for 341 example, native broadcast and multicast. It seems feasible to apply 342 the 802.16's Ethernet CS to configure this link model. However, the 343 802.16's MAC feature is still connection-oriented not providing 344 multicast and broadcast connection for IP packet transfer. There 345 needs mechanisms like IEEE 802.1D to realize multicast and broadcast 346 for Ethernet CS. Moreover, the frequent IP multicast and broadcast 347 signaling within the IP subnet like Ethernet needs to be avoided not 348 to wake up sleep/idle [IEEE802.16e] SSs. 350 The last shared IPv6 prefix link model eventually results in multi- 351 link subnet problems [RFC4903]. In 802.16, BS assigns separate 352 802.16 connections for SSs. Therefore, SSs are placed on the 353 different links. In this situation, distributing shared IPv6 prefix 354 for SSs which are placed on the different links causes the multi-link 355 subnet problems. This is valid for IP CS and even to the Ethernet CS 356 if any bridging functionality is not implemented on top of BS or 357 between BS and AR. 359 We identified the feasible IP Subnet models for IEEE 802.16 networks 360 depending on the convergence sublayers. At the current stage, only 361 the IP CS and Ethernet CS of IEEE 802.16 are within the 16ng scope. 362 Followings are the feasible IP Subnet models for each convergence 363 sublayer used. 365 1. Point-to-Point Link model for IP CS. 367 2. Ethernet like Link Model for Ethernet CS. 369 According to the point-to-point feature of 802.16's MAC, the Point- 370 to-Point link model is the feasible IP Subnet model for IP CS under 371 considering the multilink subnet problems. For the Ethernet CS, the 372 Ethernet like link model is the feasible IP Subnet model. However, 373 in this model unnecessary multicast and broadcast packets within an 374 IP Subnet should be minimized. 376 4.2. Point-to-Point Link model for IP CS: Problems 378 - Address Resolution: 380 Address Resolution is the process by which IP nodes determine the 381 link- layer address of a destination node on the same IP Subnet given 382 only the destination's IP address. In case of IPCS, the ARP cache or 383 Neighbor cache as 802.16 MAC address is never used as part of the 384 802.16 frame. Thus, performing the address resolution may be 385 redundant in case of IPCS. For IPv4, blocking ARP needs to be 386 implemented by SS itself in an implementation specific fashion not to 387 send the unnecessary broadcast (Ethernet) frames over the air. For 388 IPv6, address resolution is the function of IP layer and the IP 389 reachability state is maintained through neighbor discovery packets. 390 Therefore, blocking neighbor discovery packets would break the 391 neighbor unreachability detection model. 393 -Router Discovery: 395 BS needs to send the RA with separate IP prefix in unicast manner for 396 each SS explicitly to send periodic router advertisements in 802.16 397 Networks. 399 - Prefix Assignment: 401 Separate IP prefix should be distributed for each SS to locate them 402 on different IP Subnets. When a SS moves between BSs under the same 403 AR, the AR needs to redistribute the same IP Subnet prefix which the 404 SS used at the previous BS. 406 - Next-Hop: 408 SS's next-hop always needs to be the AR which provides the IP 409 connectivity at that access network. 411 - Neighbor Unreachability Detection (NUD): 413 Because SS always see an AR as the next hop, the NUD is required only 414 for that AR. Also the requirement of NUD may depend on the existence 415 of a connection to the BS for that particular destination. 417 - Address Autoconfiguration: 419 Because a unique prefix is assigned to each SS, the IP Subnet 420 consists of only one SS and an AR. Therefore, duplicate address 421 detection (DAD) is trivial. 423 4.3. Ethernet like Link model for Ethernet CS: Problems 425 - Address Resolution: 427 For Ethernet CS, sender needs to perform an address resolution to 428 fill the destination Ethernet address field even though that address 429 is not used for transmitting an 802.16 frame on the air. That 430 Ethernet destination address is used for a BS or bridge to decide 431 where to forward that Ethernet frame after decapsulating the 802.16 432 frame. When the destination's IP address has the same address prefix 433 with its own, the sender should set the Ethernet frame's destination 434 address as the destination itself. To acquire that address, the 435 address resolution should be performed throughout conventional 436 broadcast and multicast based ARP or NDP. However, if not filtered 437 (e.g., [RFC4541]), these multicast and broadcast packets result in 438 the problem of waking up the sleep/idle [IEEE802.16e] SSs. 440 - Router Discovery: 442 All SSs under the AR are located in the same broadcast domain in the 443 Ethernet like link model. In this environment, sending periodic 444 Router Advertisements with the destination of all-nodes multicast 445 address results in the problem of waking up the sleep/idle 446 [IEEE802.16e] SSs. 448 - Prefix Assignment: 450 Because the same IP prefix is shared with multiple SSs, an IP Subnet 451 consists of multiple SSs and an AR. SS assumes that there exist on- 452 link neighbors and tries to resolve the L2 address for the on-link 453 prefixes. However, direct communication using link layer address 454 between two SSs is not possible only with Ethernet CS without adding 455 bridging functionality on top of BS or between BS and AR. 457 - Next-Hop: 459 When Ethernet CS is used and the accompanying Ethernet capability 460 emulation is implemented, the next-hop for the destination IP with 461 the same global prefix with the sender or link local address type 462 should be the destination itself not an AR. 464 - Neighbor Unreachability Detection (NUD): 466 All SSs under the same AR are all the neighbors. Therefore, the NUD 467 is required for all the SSs and AR. 469 - Address Autoconfiguration: 471 The duplicate address detection (DAD) should be performed among 472 multiple SSs and an AR which are using the same IP prefix. The 473 previous multicast based DAD cause the problem of waking up the 474 sleep/idle [IEEE802.16e] SSs. 476 4.4. IP over IEEE 802.16 Goals 478 The following are the goals in no particular order that point at 479 relevant work to be done in IETF. 481 Goal #1. Define the way to provide the point-to-point link model for 482 IP CS. 484 Goal #2. Reduce the power consumption caused by waking up sleep/idle 485 [IEEE802.16e] terminals for Ethernet like link model. 487 Goal #3. Do not cause multilink subnet problems. 489 Goal #4. Provide the applicability of the previous security works 490 like SEND [RFC3971]. 492 Goal #5. Do not introduce any new security threats. 494 5. IANA Considerations 496 This document does not require any actions from IANA. 498 6. Security Considerations 500 This documents describes the problem statement and goals for IP over 501 802.16 networks and does not introduce any new security threats. 503 7. Acknowledgment 505 The authors would like to express special thank to David Johnston for 506 amending the section 4, "Overview of the IEEE 802.16-2006 MAC layer" 507 and carefully reviewing the entire document and also to Phil Roberts 508 for suggesting the reorganization of the document depending on the 509 baseline IP subnet models. 511 The authors also would like to express thank to Jari Arkko, HeeYoung 512 Jung, Myung-Ki Shin, Eun-Kyoung Paik, Jaesun Cha and KWISF (Korea 513 Wireless Internet Standardization Forum) for their comments and 514 contributions. 516 8. References 518 8.1. Normative References 520 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 521 RFC 1661, July 1994. 523 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 524 Neighbor Discovery (SEND)", RFC 3971, March 2005. 526 8.2. Informative References 528 [IEEE802.16] 529 IEEE Std 802.16-2004, "IEEE Standard for Local and 530 metropolitan area networks, Part 16: Air Interface for 531 Fixed Broadband Wireless Access Systems", October 2004. 533 [IEEE802.16e] 534 IEEE Std 802.16e, "IEEE standard for Local and 535 metropolitan area networks, Part 16:Air Interface for 536 fixed and Mobile broadband wireless access systems", 537 October 2005. 539 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 540 "Considerations for Internet Group Management Protocol 541 (IGMP) and Multicast Listener Discovery (MLD) Snooping 542 Switches", RFC 4541, May 2006. 544 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 545 June 2007. 547 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 548 Based Networks", RFC 4968, August 2007. 550 Authors' Addresses 552 Junghoon Jee 553 ETRI 555 Email: jhjee@etri.re.kr 557 Syam Madanapalli 558 LogicaCMG 560 Email: smadanapalli@gmail.com 562 Jeff Mandin 563 Runcom 565 Email: jeff@streetwaves-networks.com 567 gabriel_montenegro_2000@yahoo.com 568 Microsoft 570 Email: gabriel_montenegro_2000@yahoo.com 572 Soohong Daniel Park 573 Samsung Electronics 575 Email: soohong.park@samsung.com 577 Max Riegel 578 Nokia Siemens Networks 580 Email: maximilian.riegel@nsn.com 582 Full Copyright Statement 584 Copyright (C) The IETF Trust (2007). 586 This document is subject to the rights, licenses and restrictions 587 contained in BCP 78, and except as set forth therein, the authors 588 retain all their rights. 590 This document and the information contained herein are provided on an 591 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 592 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 593 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 594 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 595 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 596 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 Intellectual Property 600 The IETF takes no position regarding the validity or scope of any 601 Intellectual Property Rights or other rights that might be claimed to 602 pertain to the implementation or use of the technology described in 603 this document or the extent to which any license under such rights 604 might or might not be available; nor does it represent that it has 605 made any independent effort to identify any such rights. Information 606 on the procedures with respect to rights in RFC documents can be 607 found in BCP 78 and BCP 79. 609 Copies of IPR disclosures made to the IETF Secretariat and any 610 assurances of licenses to be made available, or the result of an 611 attempt made to obtain a general license or permission for the use of 612 such proprietary rights by implementers or users of this 613 specification can be obtained from the IETF on-line IPR repository at 614 http://www.ietf.org/ipr. 616 The IETF invites any interested party to bring to its attention any 617 copyrights, patents or patent applications, or other proprietary 618 rights that may cover technology that may be required to implement 619 this standard. Please address the information to the IETF at 620 ietf-ipr@ietf.org. 622 Acknowledgment 624 Funding for the RFC Editor function is provided by the IETF 625 Administrative Support Activity (IASA).