idnits 2.17.1 draft-kaippallimalil-netext-pmip-qos-wifi-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 15 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 15 has weird spacing: '...o match bandw...' == Line 95 has weird spacing: '...lues in downs...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 21, 2013) is 4022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 144, but not defined == Missing Reference: 'GSMA-IR34' is mentioned on line 185, but not defined == Unused Reference: 'KEYWORDS' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC 2211' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'RFC 2212' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC 2216' is defined on line 464, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netext-pmip6-qos-00 Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Kaippallimalil 3 Intended Status: Informational Huawei 4 Expires: October 23, 2013 April 21, 2013 6 Mapping PMIP Quality of Service in WiFi Network 7 draft-kaippallimalil-netext-pmip-qos-wifi-02 9 Abstract 11 This document proposes a model for configuring and mapping PMIP QoS 12 parameters of a mobile network session to the corresponding 13 connection at a WiFi Access Point. In congested network conditions, 14 it is useful for an MN's flows to be policed and shaped at the WLC 15 and WiFi AP to match bandwidth constraints or service priority of 16 the user's subscription. Applying similar QoS management at the WiFi 17 AP and WLC allows optimal use of network resources. Currently, the 18 WiFi AP does not have information on the MNs subscribed bandwidth, or 19 relative priority of its flows or services for per user QoS handling 20 at the WiFi AP. This document provides a model for mapping PMIP QoS 21 to corresponding 802.11e QoS parameters. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. QoS Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. QoS in Mobile Networks . . . . . . . . . . . . . . . . . . 4 66 2.2. QoS in WiFi Networks . . . . . . . . . . . . . . . . . . . 5 67 3. Connection Model . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Policy Provisioning Architecture . . . . . . . . . . . . . . . 7 69 5. QoS Configuration and Mapping . . . . . . . . . . . . . . . . . 8 70 5.1. PMIP - 802.11e QoS Configuration . . . . . . . . . . . . . 8 71 5.2. Mapping Recommendations and Default Values . . . . . . . . 9 72 6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 This document describes a means for the QoS profile of a PMIP session 83 to be applied to QoS on the 802.11 connection segment of the MN 84 (Mobile Node). A mobile network may dynamically provision QoS for its 85 users attached via a WiFi access and PMIP backhaul. [PMIP-QoS] 86 defines a mechanism by which QoS policy parameters in the mobile 87 network are delivered from the LMA to the the WLC (MAG) using PMIP 88 QoS extensions. [PMIP-QoS] further describes how the DSCP value for 89 the PMIP session is mapped to corresponding 802.1p value that may be 90 used by IP backhaul network or WiFi APs to prioritize IP flows of a 91 host (MN). 93 While [PMIP-QoS] defines how mobile network QoS can be applied to 94 PMIP flows, the WiFi AP has to reflexively map QoS for IP flows. 95 Based on the observed DSCP values in downstream packets of an IP 96 flow, the WiFi AP provides the same level of QoS in the upstream 97 direction. In addition, the WiFi AP may use the downstream DSCP 98 values to determine the scheduling priority in the 802.11 network. 99 Based on [PMIP-QoS], the WLC (MAG) can use DSCP priority as well as 100 other parameters of the MN such as subscribed bandwidth and service 101 priority to police IP flows of an MN. The WiFi AP on the other hand 102 relies on DSCP priority for scheduling and policing IP flows of an MN 103 since it does not have per subscriber policy information of an MN. In 104 congested network conditions, it is not possible for the WiFi AP to 105 differentiate between MNs that have premium subscriptions. In 106 addition, it is possible that upstream flows from the WiFi AP are 107 throttled by the WLC to match the bandwidth constraints or service 108 priority. This can result in sub-optimal use of network resources. In 109 order for the WiFi AP to differentiate on per flow and per user 110 basis, it needs information on the MNs subscribed bandwidth and other 111 policy information. 113 This proposal aims to provide the WiFi AP with per MN QoS profile to 114 allow more effective overall use of network resources - both WiFi 115 radio and IP backhaul. The QoS parameters needed are available to the 116 WLC during MN authorization and establishment of the PMIP session 117 with QoS extensions. Since an MN may establish tunneled IP flows, 118 direct IP connections or offloaded connections, the relationship of 119 PMIP QoS to 802.11e QoS is explained. It is possible that an MN (with 120 a single 802.11 interface) has more than one PMIP session. The QoS 121 policy for the MN may be applied by the AP to schedule and control 122 WiFi radio network resources and upstream user flows in the IP 123 backhaul network. If per session QoS policy is not available, the AP 124 may be provisioned to apply QoS based on the subscribed QoS values 125 obtained during 3GPP user authorization. 127 In order to provision QoS in the WiFi network, a consistent mapping 128 of QoS parameters and values between 3GPP and 802.11e is needed. 129 Recommendations to map 3GPP QCI to DSCP for mobility sessions are 130 available in [PMIP-QoS]. This document adds the configuration of QoS 131 per PMIP mobility session to a WiFi radio access. 133 The rest of the document is organized as follows. Chapter 2 outlines 134 the QoS mechanisms in 3GPP mobile networks and 802.11 networks. 135 Chapter 3 provides an overview of the architecture in which QoS is 136 provisioned on the WiFi AP. Chapters 4 and 5 describe the connection 137 model in the access network and the QoS mapping itself. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 1.2. Definitions 147 1.3. Abbreviations 149 3GPP Third Generation Partnership Project 150 AAA Authentication Authorization Accounting 151 ARP Allocation and Retention Priority 152 AP Access Point 153 DSCP Differentiated Services Code Point 154 EPC Enhanced Packet Core 155 GBR Guaranteed Bit Rate 156 MAG Mobility Access Gateway 157 MBR Maximum Bit Rate 158 MN Mobile Node 159 PDN-GW Packet Data Network Gateway 160 QCI QoS Class Indicator 161 QoS Quality of Service 162 Tspec Traffic Conditioning Spec 163 WLC Wireless Controller 165 2. QoS Mechanisms 167 2.1. QoS in Mobile Networks 169 3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release 170 8 [TS 23.107]. 3GPP QoS policy configuration defines access agnostic 171 QoS parameters that can be used to provide service differentiation in 172 multi vendor and operator deployments. The concept of a bearer is 173 used as the basic construct for which the same QoS treatment is 174 applied for uplink and downlink packet flows between the MN (host) 175 and gateway [TS23.401]. A bearer may have more than one packet filter 176 associated and this is called a Traffic Flow Template (TFT). The IP 177 five tuple (IP source address, port, IP destination, port, protocol) 178 identifies a flow. 180 The access agnostic QoS parameters associated with each bearer are 181 QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), 182 MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate). QCI 183 is a scalar that defines packet forwarding criteria in the network. 184 Mapping of QCI values to DSCP is well understood and GSMA has defined 185 standard means of mapping between these scalars [GSMA-IR34]. 187 An MN may have more than one IP addresses associated with the same 188 hardware (MAC) address corresponding to each of the networks than it 189 is attached to. This corresponds to more than one PMIP mobility 190 session for which QoS is provisioned in the WLC. 192 2.2. QoS in WiFi Networks 194 802.11e [802.11e] defined by IEEE provides an enhancement of the MAC 195 layer in WiFi networks to support QoS. Basic 802.11 WiFi uses CSMA 196 and collision avoidance to provide best effort access to the medium. 197 802.11e defines a Hybrid Coordination Function (HCF) that provides a 198 priority based access and also admission control based access. 200 HCF contention based channel access provides prioritized access to 201 the 802.11 medium. Four access categories (AC) are defined based on 202 traffic type. Each arriving frame is mapped into one of four FIFO 203 queues corresponding to different user priority (UP) values. The 204 highest priority frame is transmitted when access is obtained in a 205 contention window. Access categories and their mapping to 802.1D user 206 priorities is provided [802.11e]. 208 HCF controlled channel access uses a central coordinator to provide 209 contention free access to the medium based on admission control. The 210 HCCA (HCF Controlled Channel Access) based scheduling can use 211 configured policies to grant exclusive access to a QSTA (user) for 212 limited contention free slots. 214 3. Connection Model 215 MNs that attach to a mobile network via a WiF AP and WLC are 216 provisioned with IP addresses corresponding to each PMIP session. 217 Each of the IP sessions at MN has QoS policies associated to it. This 218 section outlines the connection model in detail and QoS mapping on 219 the WiFi AP. 221 WiFi AP WLC(MAG) 222 +----------+ +-------------+ 223 |+--------+| | +---------+ | 224 +---+ || PEP || | + PEP + | 225 |MN | |+--------+| | +---------+ | 226 | 1 ===========================[conn-1]================[PMIP-1] 227 +---+ | | | | 228 +---+ | | | | 229 |MN +--------------------------[conn2a]---------=======[PMIP-2] 230 | 2 +--------------------------[conn2b]--------- | 231 +---+ +----------+ +------|------+ 232 | 233 V 234 [offload path] 236 Figure 1: MN Connection model 238 An MN may establish a session to the mobile network or may have a 239 session that is offloaded to the internet from the WLC. 240 Figure 2 shows MN1 and MN2 attached to the WLC via a WiFi AP. An MN 241 may have a tunneled connection to the mobile network (MN1, conn-1, 242 PMIP-1), (MN2, conn2a, PMIP-2) and an IP connection that is offloaded 243 at the WLC (MN2, conn2b, offload). The specification for IP 244 tunnel/connection between MN and WLC are out of the scope of this 245 document. 247 For an MN - WLC connection segment with IP address configured via 248 PMIP (e.g. MN2 conn2a), the corresponding PMIP QoS would be 249 applicable to MN flows with this IP address. 250 For connection segment that is offloaded at WLC, the IP address is 251 configured by the WLC. As in the case of PMIP connections, QoS is 252 provisioned for MN flows with this IP address 254 In both cases - PMIP session related connection segment, or offload 255 connection segment - the WiFi AP gets QoS traffic filters and 256 configuration from the WLC. The QoS profile would be identified by 257 the IP address for the PMIP / offload session. 259 4. Policy Provisioning Architecture 261 This section describes the architecture in which the PMIP QoS 262 configuration of MN sessions is applied to the corresponding traffic 263 flows in the WiFi Access Point. Following MN attach to the WiFi 264 network and authentication with the mobile network, the WLC gets QoS 265 parameters and other policy for the authorized MN. When the PMIP 266 connection is created, the PDN-GW returns QoS policy using [PMIP-QoS] 267 extensions. 269 In [PMIP-QoS], the Access Point (AP) is not directly provisioned with 270 QoS for an MN connection. As a result, the AP is only able to 271 prioritize flows based on observed downlink DSCP values. 272 Additionally, the AP does not know the maximum bandwidth of a 273 subscriber or flow to be applied on the WiFi radio network. This can 274 result in sub-optimal utilization of scarce WiFi network resources, 275 and of the overall access network. This solution provides a 276 description to provision the AP with QoS policy associated to an MN. 278 The paragraphs that follow outline the overall architecture and 279 subsequent chapters provide details on QoS parameters provisioned in 280 the AP. 282 +-----+ 283 | AAA | 284 +--+--+ 285 | 286 |Auth 287 | 288 WiFi AP WLC(MAG)| 289 +----------+ +------|------+ 290 |+--------+| QoS | +----v----+ | PMIP-QoS +------+ 291 ||QoS-Ctrl<------------+QoS-Ctrl <------------+PDN-GW+ 292 |+---+----+| Policy | +----+----+ | +--+---+ 293 | | | | | | | 294 801.11 |+---v----+| _____ | +----V----+ | ________ | 295 [MN]--------+ PEP +--/ IP )---+ PEP +----/ IP ) | 296 |+--------+| Network | +---------+ | | Network|-+ 297 +----------+ ( / +-------------+ ( / 298 ----- .------. 300 Figure 2: Architecture for provisioning QoS Policy on WiFi AP 302 Figure 1 provides an overview of the architecture in which QoS for an 303 MN is provisioned on the AP. MN QoS policy from initial session 304 authorization and PMIP connection establishment is provisioned in the 305 WLC QoS-Ctrl (logical function). QoS-Ctrl in WLC installs QoS to the 306 WLC PEP as described in [PMIP-QoS]. 307 The WLC translates 3GPP QoS policy to equivalent parameters for IP 308 flows and applies them for scheduling and policing. 310 In this solution, the WLC sends policy information for an MNs PMIP 311 sessions to the WiFi AP. The protocols used to exchange QoS 312 parameters between the WLC and AP are not discussed in this document. 313 The AP can use the received QoS policy configuration and applies them 314 to upstream and downstream forwarding of data packets in the WiFi 315 radio network. The AP can also apply these QoS policies for upstream 316 user IP flows to the WLC. 318 An MN may have more than one PMIP session at any given time. Each of 319 these PMIP sessions can have different policy parameters. The WLC 320 provides the WiFi AP with a policy corresponding to each of these 321 PMIP sessions. Since each PMIP session configures an IP address for 322 the MN, the policy can be sent per IP address of MN that corresponds 323 to the PMIP session. This model is described further in the following 324 chapter. 326 If the MN connection at WLC is offloaded to the internet, there is no 327 PMIP session setup to the mobile network. In this case, the WLC 328 should use the subscriber policy obtained during authorization. The 329 WiFi AP is provisioned as for other sessions. The WLC provides the 330 WiFi AP with QoS parameters for the MN IP address used for the 331 offload connection. 333 5. QoS Configuration and Mapping 335 5.1. PMIP - 802.11e QoS Configuration 337 The WiFi Access Point (AP) gets QoS configuration per IP session from 338 the WLC. The QoS information per IP session provided to the AP 339 includes: 340 - Hardware (MAC) address of host for which PMIP session is 341 established. 342 - IP prefix or address of PMIP mobility session. 343 - IP port address (used for NATed connections). 344 - DSCP. Diffserv PHB value of PMIP QoS for the mobility session. 345 - QCI. The WLC provides the 3GPP QCI value if available, for example, 346 from authorization profile of APN (i.e. subscribed values per 347 established PMIP mobility session). 348 - ARP (Allocation and Retention Priority). This value is obtained 349 from the PMIP QoS for the mobility session. It determines the 350 priority of a flow (1 has highest priority). 351 - MBR (Maximum Bit Rate) for mobility session uplink and downlink. 352 This should not exceed the AMBR (Aggregate MBR) of the 353 subscription. 354 - GBR (Guaranteed Bit Rate) for mobility session uplink and downlink, 355 if required. 357 The WiFi AP uses the above QoS configuration to implement 358 classification, admission control and forwarding of MN flows. The 359 WiFi AP maps DSCP (or QCI) to 802.11e AC (Access Categories) for each 360 IP session / hardware (MAC) address of the host (3GPP user). The 361 mapping from DSCP or QCI to 802.11e AC is shown in table in chapter 4 362 below. 364 In the WiFi radio network, the AP uses 802.11e AC values for 365 contention (HCF) based forwarding based on priority. The AP schedules 366 downstream flows in the WiFi radio network and for upstream IP 367 backhaul to the WLC. For contention free scheduling, the WiFi AP 368 additionally uses the QoS configuration per user to admit flows 369 based on 802.11e ADDTS (ADD TSpec) requests from the host (3GPP 370 user). The WiFi AP may drop packet that fall outside the configured 371 MBR and GBR. In case of severe radio congestion, the WiFi AP can use 372 ARP in addition to DSCP drop precedence to determine the flows to be 373 dropped. 375 5.2. Mapping Recommendations and Default Values 377 The table below outlines a recommended mapping between 3GPP QCI, 378 and 802.11e Access Category (AC) priorities. QCI packet delay budget 379 and packet error loss rate may be used by the WiFi access point in 380 scheduling contention free access when HCCA scheduling is used. 382 QCI DSCP 802.11e AC Example 3GPP service 383 ------------------------------------------------------------- 384 1 EF 3 AC_VO conversational voice 385 2 EF 3 AC_VO conversational video 386 3 EF 3 AC_VO real-time gaming 387 4 AF41 2 AC_VI buffered streaming 388 5 AF31 2 AC_VI IMS signaling 389 6 AF31 2 AC_VI buffered streaming 390 7 AF21 0 AC_BE interactive gaming 391 8 AF11 0 AC_BE web access 392 9 BE 1 AC_BK e-mail 394 Table 1: QoS Mapping between QCI, WMM, 802.11e AC 396 6. Next Steps 398 This document has described a basic model for mapping PMIP QoS 399 parameters to 802.11e parameters. However, there are a few questions 400 that need to be explored further. 402 The protocol between WLC and AP is not discussed in this document. 403 There needs to be work to determine the protocol specification if it 404 is desired that WLC and AP should interwork for QoS capability. 406 Another aspect is this draft does not describe multiple PDN 407 connections per MN in much detail. This is work in progress in 3GPP 408 and the results should be compatible with the model in this draft. 410 RTC Web impact to 3GPP networks is currently being studied. There are 411 several technical options being considered by 3GPP at this time. If 412 the chosen solution requires more than one type of DSCP/QoS to be 413 configured per PMIP session/IP connection segment - for example if 414 audio and video flows use the same IP session - then this capability 415 is required for WLC - AP configuration also. 417 Finally, the QoS values listed in the table in chapter 5 needs to be 418 aligned with [PMIP-QoS] and GSMA. 420 7. Security Considerations 422 This document describes mapping of 3GPP QoS profile and parameters to 423 IEEE 802.11e parameters. No security concerns are expected as a 424 result of using this mapping. 426 8. IANA Considerations 428 No IANA assignment of parameters are required in this document. 430 9. References 432 9.1. Normative References 434 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 438 1 1995. 440 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 441 April 1 1996. 443 9.2. Informative References 445 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 446 RFC 3514, April 1 2003. 448 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 449 Acronyms", RFC 5513, April 1 2009. 451 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 452 2009. 454 [PMIP-QoS] Liebsch, et al., "Quality of Service Option for Proxy 455 Mobile IPv6", draft-ietf-netext-pmip6-qos-00, June 2012. 457 [RFC 2211] Wroclawski, J., "Specification of the Controlled Load 458 Quality of Service", RFC 2211, September 1997. 460 [RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 461 of Guaranteed Quality of Service", RFC 2212, September 462 1997. 464 [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS 465 Control Service Specification Template", RFC 2216, 466 September 1997. 468 [TS23.107] Quality of Service (QoS) Concept and Architecture, Release 469 10, 3GPP TS 23.107, V10.2.0 (2011-12). 471 [TS23.207] End-to-End Quality of Service (QoS) Concept and 472 Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011- 473 03). 475 [TS23.401] General Packet Radio Service (GPRS) enhancements for 476 Evolved Universal Terrestrial Radio Access Network (E- 477 UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 478 06). 480 [TS23.203] Policy and Charging Control Architecture, Release 11, 3GPP 481 TS 23.203, V11.2.0 (2011-06). 483 [TS29.212] Policy and Charging Control over Gx/Sd Reference Point, 484 Release 11, 3GPP TS 29.212, V11.1.0 (2011-06). 486 [802.11e] IEEE, "IEEE part 11: Wireless LAN Medium Access 487 Control(MAC) and Physical Layer (PHY) specifications. 488 Amendment 8: Medium Access Control (MAC) Quality of 489 Service Enhancements" 802.11e-2005, 22 September 2005. 491 [GSMA-IR34]Inter-Service Provider Backbone Guidelines 5.0, 22 492 December 2010 494 Authors' Addresses 496 John Kaippallimalil 497 5340 Legacy Drive, Suite 175 498 Plano Texas 75024 500 E-Mail: john.kaippallimalil@huawei.com