idnits 2.17.1 draft-ietf-dime-pmip6-lr-18.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 340 has weird spacing: '...nchored o---...' -- The document date (August 2, 2012) is 4285 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) == Outdated reference: A later version (-14) exists of draft-ietf-dime-rfc4005bis-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track Q. Wu 5 Expires: February 3, 2013 Huawei 6 J. Korhonen 7 NSN 8 August 2, 2012 10 Diameter Support for Proxy Mobile IPv6 Localized Routing 11 draft-ietf-dime-pmip6-lr-18 13 Abstract 15 In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the 16 Mobile Access Gateway (MAG) to which it is attached are typically 17 tunneled to a Local Mobility Anchor (LMA) for routing. The term 18 "localized routing" refers to a method by which packets are routed 19 directly between an MN's MAG and the MAG of its Correspondent Node 20 (CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, 21 it may be desirable to control the establishment of localized routing 22 sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring 23 that the session be authorized. This document specifies how to 24 accomplish this using the Diameter protocol. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 3, 2013. 43 Copyright Notice 45 Copyright (c) 2012 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Attribute Value Pair Used in this Document . . . . . . . . . . 4 64 4.1. User-Name AVP . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 5 66 4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 5 67 4.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 5 68 5. Example Signaling Flows for Localized Routing Service 69 Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobility Access 82 Gateway (MAG) to optimize media delivery by locally routing packets 83 from a Mobile Node to a Correspondent Node that is locally attached 84 to an access link connected to the same Mobile Access Gateway, 85 avoiding tunneling them to the Mobile Node's Local Mobility Anchor 86 (LMA). This is referred to as "local routing" in RFC 5213. However, 87 this mechanism is not applicable to the typical scenarios in which 88 the MN and CN are connected to different MAGs and are registered to 89 the same LMA or different LMAs. [RFC6279] takes those typical 90 scenarios into account and defines the problem statement for PMIPv6 91 localized routing. [I-D.ietf-netext-pmip-lr] specifies the PMIPv6 92 localized routing protocol based on the scenarios A11, A12, and A21 93 [RFC6279], which is used to establish a localized routing path 94 between two Mobile Access Gateways in a PMIPv6 domain. 96 However, there is no relevant work discussing how AAA-based 97 mechanisms can be used to provide authorization to the Mobile Node's 98 MAG or LMA for enabling localized routing between MAGs. 100 This document describes Diameter [I-D.ietf-dime-rfc3588bis] support 101 for the authorization of PMIPv6 mobility entities in case of 102 A11,A12,A21 during localized routing. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 3. Solution Overview 112 This document addresses how to provide authorization to the Mobile 113 Node's MAG or LMA for enabling localized routing and resolve the 114 destination MN's MAG by means of interaction between the LMA and the 115 AAA server. Figure 1 shows the reference architecture for Localized 116 Routing Service Authorization. This reference architecture assumes 117 that 119 o If MN and CN belong to different LMAs, MN and CN should share the 120 same MAG (i.e.,A12 described in [RFC6279]), e.g., MN1 and CN2 in 121 Figure 1 are attached to the same MAG1 and belong to LMA1 and LMA2 122 respectively. Note that LMA1 and LMA2 in Figure 1 are in the same 123 provider domain (as described in [RFC6279]). 125 o If MN and CN are attached to the different MAGs, MN and CN should 126 belong to the same LMA (i.e.,A21 described in [RFC6279]), e.g., 127 MN1 and CN3 in theFigure 1 are attached to the MAG1 and MAG3 128 respectively but belong to LMA1. 130 o MN and CN may belong to the same LMA and are attached to the same 131 MAG(i.e.,A11 described in [RFC6279]), e.g.,MN1 and CN1 in the 132 Figure 1 are both attached to the MAG1 and belong to LMA1. 134 o The MAG and LMA support Diameter client functionality. 136 +---------+ 137 +---------------------->| AAA & | 138 | +------>| Policy | 139 | | | Profile | 140 | Diameter +---------+ 141 | | 142 | +--V-+ +----+ 143 | +------->|LMA1| |LMA2| 144 | | +---++ +----+ 145 | | | | | 146 Diameter | | +-------+--------- 147 | | | | | 148 | PMIP | | \\ 149 | | // // \\ 150 | | // // \\ 151 | | // // \\ 152 | | | | | 153 | +---->+---------------+ +----+ 154 | | MAG1 | |MAG3| 155 +-------->+---------------+ +----+ 156 : : : : 157 +---+ +---+ +---+ +---+ 158 |MN1| |CN1| |CN2| |CN3| 159 +---+ +---+ +---+ +---+ 161 Figure 1: Localized Routing Service Authorization Reference 162 Architecture 164 The interaction of the MAG and LMA with the AAA server according to 165 the extension specified in this document is used to authorize the 166 localized routing service. 168 4. Attribute Value Pair Used in this Document 170 This section describes Attribute Value Pairs (AVPs) defined by this 171 specification or re-used from existing specifications in a PMIPv6- 172 specific way. 174 4.1. User-Name AVP 176 The User-Name AVP (AVP Code 1) is defined in 177 [I-D.ietf-dime-rfc3588bis]. This AVP is used to carry the MN- 178 Identifier (Mobile Node identifier) [RFC5213] in the AA-Request (AAR) 179 message [I-D.ietf-dime-rfc4005bis]. 181 4.2. PMIP6-IPv4-Home-Address AVP 183 The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in 184 [RFC5779]. This AVP is used to carry the IPv4-MN-HoA (Mobile Node's 185 IPv4 home address)[RFC5844] in the AA-Request (AAR) message 186 [I-D.ietf-dime-rfc4005bis]. 188 4.3. MIP6-Home-Link-Prefix AVP 190 The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779]. 191 This AVP is used to carry the MN-HNP (Mobile Node's home network 192 prefix) in the AAR. 194 4.4. MIP6-Feature-Vector AVP 196 The MIP6-Feature-Vector AVP is defined in [RFC5447]. This document 197 allocates a new capability flag bit according to the IANA rules in 198 RFC 5447. 200 INTER_MAG_ROUTING_SUPPORTED (TBD) 202 Direct routing of IP packets between MNs anchored to different 203 MAGs without involving any LMA is supported. This bit is used 204 with MN-Identifier. When a MAG or LMA sets this bit in the MIP6- 205 Feature-Vector and MN-Identifier corresponding to the Mobile Node 206 is carried with this bit, it indicates to the home AAA server 207 (HAAA) that the Mobile Node associated with this LMA is allowed to 208 use localized routing.If this bit is cleared and MN-Identifier 209 corresponding to the Mobile Node is carried with this bit, it 210 indicates to the home AAA server (HAAA) that the Mobile Node 211 associated with this LMA is not allowed to use localized routing. 212 When a MAG or LMA sets this bit in the MIP6-Feature-Vector and MN- 213 Identifiers corresponding to the Mobile Node and Correspondent 214 Node are both carried with this bit, it indicates to the HAAA that 215 localized routing of IP packets between Mobile Node and 216 Correspondent Node anchored to different MAGs is supported. If 217 this bit is cleared and MN- Identifiers corresponding to the 218 Mobile Node and Correspondent Node are both carried with this bit 219 to HAAA, it indicates to the HAAA that localized routing of IP 220 packets between Mobile Node and Correspondent Node anchored to 221 different MAGs is not supported. If this bit is cleared in the 222 returned MIP6-Feature-Vector AVP, the HAAA does not authorize 223 direct routing of packets between MNs anchored to the different 224 MAG. The MAG and LMA MUST support this policy feature on a per-MN 225 and per-subscription basis. 227 5. Example Signaling Flows for Localized Routing Service Authorization 229 Localized Routing Service Authorization can happen during the network 230 access authentication procedure [RFC5779] before localized routing is 231 initialized. In this case, the preauthorized pairs of LMA/prefix 232 sets can be downloaded to Proxy Mobile IPv6 entities during the RFC 233 5779 procedure. Localized routing can be initiated once the 234 destination of a received packet matches one or more of the prefixes 235 received during the RFC 5779 procedure. 237 Figure 2 shows an example scenario in which MAG1 acts as a Diameter 238 client, processing the data packet from MN1 to MN2 and requesting 239 authorization of localized routing (i.e.,MAG-Initiated LR 240 authorization). In this example scenario, MN1 and MN2 are attached 241 to the same MAG and anchored to the different LMAs (i.e.,A12 242 described in [RFC6279]). In this case, MAG1 knows that MN2 belongs 243 to a different LMA (which can be determined by looking up the binding 244 cache entries corresponding to MN1 and MN2 and comparing the 245 addresses of LMA1 and LMA2). In order to setup a localized routing 246 path with MAG2, MAG1 acts as Diameter client and sends an AAR message 247 to the Diameter server. The message contains an instance of the 248 MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the 249 LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5 ) set,two 250 instances of the User-Name AVP ([I-D.ietf-dime-rfc3588bis], Section 251 8.14)containing MN1-Identifier and MN2-Identifier. In addition, the 252 message may contain either an instance of the MIP6-Home-Link-Prefix 253 AVP ([RFC5779], Section 5.3) or an instance of the PMIP6-IPv4- Home- 254 Address AVP ([RFC5779], Section 5.2) containing the IP address/ HNP 255 of MN1. 257 The Diameter server authorizes localized routing service by checking 258 if MN1 and MN2 are allowed to use localized routing. If so, the 259 Diameter server responds with an AAA message encapsulating an 260 instance of the MIP6-Feature-Vector (MFV) AVP ([RFC5447], Section 261 4.2.5) with the the LOCAL_MAG_ROUTING_SUPPORTED bit 262 ([RFC5779],Section 5.5) set indicating direct routing of IP packets 263 between MNs anchored to the same MAG is supported. MAG1 then knows 264 the localized routing between MN1 and MN2 is allowed. Then MAG1 265 sends the Request messages respectively to LMA1 and LMA2. The 266 request message is the Localized Routing Initialization (LRI) message 267 in Figure 2 and belongs to the Initial phase of the localized 268 routing. LMA1 and LMA2 responds to MAG1 using the Localized Routing 269 Acknowledge message (LRA inFigure 2 ) in accordance with 270 [I-D.ietf-netext-pmip-lr]. 272 In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr],MAG1 273 should ask for authorization of localized routing again according to 274 the procedure described above before LRI is retransmitted up to a 275 maximum of LRI_RETRIES. 277 +---+ +---+ +----+ +----+ +---+ +----+ 278 |MN2| |MN1| |MAG1| |LMA1| |AAA| |LMA2| 279 +-|-+ +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ 280 | | Anchored | | | 281 o---------------------------------------------o 282 | | Anchored | | | 283 | o------------------o | | 284 | Data[MN1->MN2] | | | 285 | |------->| | | | 286 | | | AAR(MFV, MN1,MN2) | | 287 | | |------------------->| | 288 | | | AAA(MFV) | | 289 | | |<-------------------| | 290 | | | LRI | | | 291 | | |-------->| | | 292 | | | | LRI | | 293 | | |--------------------------->| 294 | | | LRA | | | 295 | | |<--------| | | 296 | | | | LRA | | 297 | | |<---------------------------| 299 Figure 2: MAG-initiated Localized Routing Authorization in A12 301 Figure 3 shows the second example scenario, in which LMA1 acts as a 302 Diameter client, processing the data packet from MN2 to MN1 and 303 requesting the authorization of localized routing. In this scenario, 304 MN1 and MN2 are attached to the different MAG and anchored to the 305 same LMA (i.e., A21 described in [RFC6279] ), LMA knows that MN1 and 306 MN2 belong to the same LMA (which can be determined by looking up the 307 binding cache entries corresponding to MN1 and MN2 and comparing the 308 addresses of LMA corresponding to MN1 and LMA corresponding to MN2). 309 In contrast with the signaling flow shown in Figure 2, it is LMA1 310 instead of MAG1 which initiates the setup of the localized routing 311 path. 313 The Diameter client in LMA1 sends an AA-Request message to the 314 Diameter server. The message contains an instance of the MIP6- 315 Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the 316 INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct 317 routing of IP packets between MNs anchored to different MAGs is 318 supported and two instances of the User-Name AVP 319 ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1-Identifier 320 and MN2-Identifier. The Diameter server authorizes the localized 321 routing service by checking if MN1 and MN2 are allowed to use 322 localized routing. If so, the Diameter server responds with an AA- 323 Answer message encapsulating an instance of the MIP6-Feature-Vector 324 (MFV) AVP ([RFC5447], Section 4.2.5) with the 325 INTER_MAG_ROUTING_SUPPORTED bit (Section 4.5) set indicating direct 326 routing of IP packets between MNs anchored to different MAGs is 327 supported. LMA1 then knows the localized routing is allowed. In 328 success case, LMA1 responds to MAG1 in accordance with 329 [I-D.ietf-netext-pmip-lr]. 331 In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr],LMA1 332 should ask for authorization of localized routing again according to 333 the procedure described above before LRI is retransmitted up to a 334 maximum of LRI_RETRIES. 336 +---+ +----+ +----+ +---+ +----+ +---+ 337 |MN1| |MAG1| |LMA1| |AAA| |MAG2| |MN2| 338 +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+-+ 339 | | | Anchored | | 340 | Anchored o-------------------+--------o 341 o--------+-------o Data[MN2->MN1] | | 342 | | |<----- | | | 343 | | |AAR(MFV,MN1,MN2) | | 344 | | |--------->| | | 345 | | | AAA(MFV) | | | 346 | | LRI |<---------| | | 347 | |<------| LRI | | 348 | | LRA |------------------>| | 349 | |------>| LRA | | 350 | | |<------------------| | 352 Figure 3: LMA-initiated Localized Routing Authorization in A21 354 Figure 4 shows another example scenario, in which LMA1 acts as a 355 Diameter client, processing the data packet from MN2 to MN1 and 356 requesting the authorization of localized routing. In this scenario, 357 MN1 and MN2 are attached to the same MAG and anchored to the same LMA 358 (i.e., A11 described in [RFC6279]), LMA knows that MN1 and MN2 belong 359 to the same LMA (which can be determined by looking up the binding 360 cache entries corresponding to MN1 and MN2 and comparing the 361 addresses of LMA corresponding to MN1 and LMA corresponding to MN2). 363 The Diameter client in LMA1 sends an AA-Request message to the 364 Diameter server. The message contains an instance of the MIP6- 365 Feature-Vector AVP ([RFC5447], Section 4.2.5) with the 366 LOCAL_MAG_ROUTING_SUPPORTED bit set and two instances of the User- 367 Name AVP ([I-D.ietf-dime-rfc3588bis], Section 8.14)containing MN1- 368 Identifier and MN2-Identifier. The Diameter server authorizes the 369 localized routing service by checking if MN1 and MN2 are allowed to 370 use localized routing. If so, the Diameter server responds with an 371 AA- Answer message encapsulating an instance of the MIP6-Feature- 372 Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the 373 LOCAL_MAG_ROUTING_SUPPORTED bit ([RFC5779],Section 5.5) set 374 indicating direct routing of IP packets between MNs anchored to the 375 same MAG is supported. LMA1 then knows the localized routing is 376 allowed and responds to MAG1 for localized routing in accordance with 377 [I-D.ietf-netext-pmip-lr]. 379 In case of LRA_WAIT_TIME expiration [I-D.ietf-netext-pmip-lr], LMA1 380 should ask for authorization of localized routing again according to 381 the procedure described above before LRI is retransmitted up to a 382 maximum of LRI_RETRIES. 384 +---+ +---+ +----+ +----+ +---+ 385 |MN2| |MN1| |MAG1| |LMA1| |AAA| 386 +-+-+ +-+-+ +-+--+ +-+--+ +-|-+ 387 | | Anchored | | 388 o-----------------------o | 389 | | Anchored | | 390 | o--------+-------o Data[MN2->MN1] 391 | | | |<----- | 392 | | | |AAR(MFV,MN1,MN2) 393 | | | |--------->| 394 | | | | AAA(MFV) | 395 | | | LRI |<---------| 396 | | |<------| | 397 | | | LRA | | 398 | | |------>| | 400 Figure 4: LMA-initiated Localized Routing Authorization in A11 402 6. Security Considerations 404 The security considerations for the Diameter NASREQ 405 [I-D.ietf-dime-rfc4005bis] and Diameter Proxy Mobile IPv6 [RFC5779] 406 applications are also applicable to this document. 408 The service authorization solicited by the MAG or the LMA relies upon 409 the existing trust relationship between the MAG/LMA and the AAA 410 server. 412 An authorised MAG could in principle track the movement of any 413 participating CNs at the level of the MAG to which they are anchored. 414 If such a MAG were compromised, or under the control of a bad-actor, 415 then such tracking could represent a privacy breach for the set of 416 tracked CNs. In such a case, the traffic pattern from the 417 compromised MAG might be notable so monitoring for e.g. excessive 418 queries from MAGs might be worthwhile. 420 7. IANA Considerations 422 This specification defines a new value in the Mobility Capability 423 registry [RFC5447] for use with the MIP6-Feature-Vector AVP: 424 INTER_MAG_ROUTING_SUPPORTED (see Section 4.4). 426 8. Contributors 428 Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early 429 versions of this document. 431 9. Acknowledgements 433 The authors would like to thank Marco Liebsch, Carlos Jesus Bernardos 434 Cano, Dan Romascanu, Elwyn Davies, Basavaraj Patil, Ralph Droms, 435 Stephen Farrel,Robert Sparks, Benoit Claise and Abhay Roy for their 436 valuable comments and suggestions on this document. 438 10. References 440 10.1. Normative References 442 [I-D.ietf-dime-rfc3588bis] 443 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 444 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 445 (work in progress), June 2012. 447 [I-D.ietf-dime-rfc4005bis] 448 Zorn, G., "Diameter Network Access Server Application", 449 draft-ietf-dime-rfc4005bis-11 (work in progress), 450 July 2012. 452 [I-D.ietf-netext-pmip-lr] 453 Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 454 Dutta, "Localized Routing for Proxy Mobile IPv6", 455 draft-ietf-netext-pmip-lr-10 (work in progress), May 2012. 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 461 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 463 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., 464 and K. Chowdhury, "Diameter Mobile IPv6: Support for 465 Network Access Server to Diameter Server Interaction", 466 RFC 5447, February 2009. 468 [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 469 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 470 Gateway and Local Mobility Anchor Interaction with 471 Diameter Server", RFC 5779, February 2010. 473 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 474 Mobile IPv6", RFC 5844, May 2010. 476 10.2. Informative References 478 [RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6 479 (PMIPv6) Localized Routing Problem Statement", RFC 6279, 480 June 2011. 482 Authors' Addresses 484 Glen Zorn 485 Network Zen 486 227/358 Thanon Sanphawut 487 Bang Na, Bangkok 10260 488 Thailand 490 Phone: +66 (0) 87-040-4617 491 Email: glenzorn@gmail.com 492 Qin Wu 493 Huawei Technologies Co., Ltd. 494 101 Software Avenue, Yuhua District 495 Nanjing, Jiangsu 21001 496 China 498 Phone: +86-25-84565892 499 Email: sunseawq@huawei.com 501 Jouni Korhonen 502 Nokia Siemens Networks 503 Linnoitustie 6 504 Espoo FI-02600, 505 Finland 507 Email: jouni.nospam@gmail.com