idnits 2.17.1 draft-yeh-dhc-dhcpv6-prefix-pool-opt-08.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 28, 2012) is 4289 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) == Missing Reference: 'TBD' is mentioned on line 443, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group L. Yeh, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Boucadair 5 Expires: January 29, 2013 France Telecom 6 T. Lemon 7 Nominum, Inc 8 J. Hu 9 China Telecom 10 July 28, 2012 12 Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers 13 draft-yeh-dhc-dhcpv6-prefix-pool-opt-08 15 Abstract 17 The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix 18 Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 19 relay agent implemented on a Provider Edge (PE) router about active 20 prefix pools allocated by the DHCPv6 server to the PE router. The 21 information of active prefix pools can be used to enforce IPv6 route 22 aggregation on the PE router by adding or removing aggregated routes 23 according to the status of the prefix pools. The advertising of the 24 aggregated routes in the routing protocol enabled on the network- 25 facing interface of PE routers will dramatically decreases the number 26 of the routing table entries in the ISP network. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 29, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 64 3. Scenario and Network Architecture . . . . . . . . . . . . . . 5 65 4. Prefix Pool Option . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 8 67 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 9. Contributors List . . . . . . . . . . . . . . . . . . . . . . 11 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 11.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 The DHCPv6 protocol [RFC3315] specifies a mechanism for the 80 assignment of IPv6 address and configuration information to IPv6 81 nodes. The DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC3633] specifies 82 a mechanism for the delegation of IPv6 prefixes from the Delegating 83 Router (DR) acting as the DHCPv6 server to the Requesting Routers 84 (RR) acting as the DHCPv6 Clients. DHCPv6 servers always maintain 85 authoritative information associated to their operations including, 86 but not limited to, the binding data of the delegated IPv6 prefixes, 87 the lease data of the delegated IPv6 prefixes, and the status of 88 their prefix pools. A prefix pool configured and maintained on the 89 server can usually be a short prefix (e.g., a /40 prefix) out of 90 which the longer prefixes (e.g., /56 prefixes) are delegated to 91 customer networks. 93 In the scenario of a centralized DHCPv6 server, the Provider Edge 94 (PE) routers act as DHCPv6 relay agents when the DHCPv6 server and 95 the Customer Edge (CE) router (a.k.a. Routed-RG or Routed-CPE) 96 acting as RRs and DHCPv6 clients are not on the same link. For 97 ensuring reachability, the PE routers always need to add or withdraw 98 the route entries directing to each customer network in their routing 99 table to reflect the status of IPv6 prefixes delegated by the DHCPv6 100 server to CE routers (see Section 6.2, [BBF TR-177]). 102 When a routing protocol is enabled on the network-facing interface of 103 the PE router, all the routes directing to the customer networks are 104 advertised in the ISP network. This will make the number of route 105 entries in the routing table on the ISP router be unacceptable large. 106 Hence, it is desirable to aggregate the routes directing to the 107 customer networks on the PE router. 109 Because the prefixes of the customer networks can not be guaranteed 110 to be active and continuous, the routing protocol enabled on the PE 111 router in general can not create one aggregated route automatically 112 to cover all the prefixes delegated within the prefix pool. One way 113 to make the aggregated routes (e.g., black-hole routes) pointing to 114 each of the prefix pools is to configure them manually and 115 permanently, but the PE router is not really aware about the status 116 of the prefix pools, especially when it acts as the relay agent. 118 This document proposes a new Prefix Pool option for the DHCPv6 relay 119 agent implemented on PE routers, allowing the DHCPv6 server to notify 120 the DHCPv6 relay agent about the prefix of pools. After the PE 121 router received information about the prefix pools, the aggregated 122 route entries per the provision status of the prefix pools can be 123 added or withdrawn in the routing table of the PE router. The 124 aggregated routes will then be advertised into the ISP network 125 through the routing protocol enabled on the PE's network-facing 126 interface. 128 DHCPv6 Bulk Leasequery [RFC5460] specifies a mechanism for bulk 129 transfer of the binding data of each delegated prefix from the server 130 to the requestor (i.e., a DHCPv6 relay agent), to support the 131 replacement or reboot event of a relay agent. In this document, the 132 capability of DHCPv6 Bulk Leasequery will be extended to support the 133 bulk transfer of the status of the prefix pools for route 134 aggregation. 136 The automatic mechanisms described in this document depends on the 137 existing DHCPv6 protocols and implementations without requiring a new 138 DHCPv6 message or a new interface for the configuration of the 139 aggregated route. The administrator of the ISP network can decide 140 whether to inject the aggregated route or not based on the policies 141 defined on the DHCPv6 server. 143 2. Terminology and Conventions 145 This document defines a new DHCPv6 option to communicate the prefix 146 of an IPv6 prefix pool. This document should be read in conjunction 147 with the DHCPv6 specifications, [RFC3315], [RFC3633], [RFC5007] and 148 [RFC5460], for understanding the complete mechanism. Definitions for 149 terms and acronyms not specified in this document are defined in 150 [RFC3315], [RFC3633], [RFC3769], [RFC5007] and [RFC5460]. 152 The following terms can be found in this document: 154 o Requesting Router (RR): A router defined in [RFC3633] that acts as 155 a DHCPv6 client, and is requesting prefix(es) to be assigned. 157 o Delegating Router (DR): A router defined in [RFC3633] that acts as 158 a DHCPv6 server, and is responding to the prefix request. 160 o Prefix Pool: An IPv6 address space allocated with a common prefix 161 out of which the longer prefixes are delegated via prefix 162 delegation. 164 o Aggregated Route: A route entry created on an edge router, is 165 based on the knowledge of a delegated prefix pool. 167 o Requestor: A router defined in [RFC5007] that acts as a DHCPv6 168 relay agent, is leasequery client. 170 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 171 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 172 document, are to be interpreted as described in BCP 14, [RFC2119]. 174 3. Scenario and Network Architecture 176 Figure 1 and Figure 2 illustrate two typical cases of the targeted 177 network architectures. 179 +------+------+ DHCPv6 Server 180 | DHCPv6 | (e.g. Binding entry 181 | Server | pe#1 - 2001:db8:1230::/44 182 | | extract PE_ID=pe#1 183 +------+------+ from the Interface_ID=pe#1_cfi#2) 184 | 185 _________|_________ 186 / \ 187 | ISP Core Network | 188 \___________________/ 189 | 190 | Network-facing interface 191 +------+------+ 192 | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor 193 | Edge | (e.g. prefix pool=2001:db8:1230::/44) 194 | Router | 195 +------+------+ 196 | Customer-facing interface 197 | (e.g. Interface_ID=pe#1_cfi#2) 198 | 199 +------+------+ 200 | Customer | DHCPv6 Client 201 | Edge | DHCPv6-PD Requesting Router 202 | Router | (e.g. customer network 203 +------+------+ =2001:db8:1234:5600:/56) 204 | 205 _________|_________ 206 / \ 207 | Customer Network | 208 \___________________/ 210 Figure 1: Use case of ISP-Customer network where CPE is directly 211 connected to PE 213 +------+------+ 214 | DHCPv6 | DHCPv6 Server 215 | Server | (e.g. Binding entry 216 | | pe#3_cfi#4 - 2001:db8:3400::/40) 217 +------+------+ 218 | 219 _________|_________ 220 / \ 221 | ISP Core Network | 222 \___________________/ 223 | 224 | Network-facing interface 225 +------+------+ 226 | Provider | DHCPv6 Relay Agent, DHCPv6 Requestor 227 | Edge | (e.g. prefix pool=2001:db8:3400::/40) 228 | Router | 229 +------+------+ 230 | Customer-facing interface 231 | (e.g. Interface_ID=pe#3_cfi#4) 232 _________|_________ 233 / \ 234 | Access Network | 235 \___________________/ 236 | 237 | 238 +------+------+ 239 | Customer | DHCPv6 Client 240 | Edge | DHCPv6-PD Requesting Router 241 | Router | (e.g. customer network 242 +------+------+ =2001:db8:1234:5600:/56) 243 | 244 _________|_________ 245 / \ 246 | Customer Network | 247 \___________________/ 249 Figure 2: Use case of ISP-Customer network where CPE is connected to 250 PE through access network 252 4. Prefix Pool Option 254 The format of the Prefix Pool option is shown in Figure 3. 256 0 1 2 3 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | OPTION_PREFIX_POOL | option-length | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | pfx-pool-len | | 262 +-+-+-+-+-+-+-+-+ ipv6-prefix + 263 | (16 octets) | 264 | | 265 | | 266 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | status | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 option-code: OPTION_PREFIX_POOL (TBD) 271 option-length: 18 272 pfx-pool-len: Length for the prefix pool in bits 273 ipv6-prefix: IPv6 prefix of the prefix pool 274 status: Status of the prefix pool, indicating the 275 availability of the prefix pool maintained 276 on the server. 278 The codes of the status are defined in the following table. 280 Name Code 281 Active 0 282 Released 1 283 Reserved 2~255 285 The 'Active' status of the prefix pool indicated in this option can 286 be used to add the prefix pool and its associated aggregated route on 287 the relay agent; while the 'Released' status of prefix pool indicated 288 in this option can be used to withdraw the prefix pool and its 289 associated aggregated route on the relay agent. 291 If the administrative policy on the DHCPv6 server permits to support 292 route aggregation on the relay agent, the status of prefix pool can 293 be determined by the delegated prefixes within the associated prefix 294 pool. If there is one delegated prefix within the pool that has a 295 valid lease, the status of the prefix pool will be 'Active'. 296 Otherwise, the status of the prefix pool is 'Released'. If the 297 administrative policy on the server does not permit to support route 298 aggregation on the DHCPv6 relay agent, the status of the prefix pool 299 will always be 'Released'. 301 Discussion: 303 The alternative option might include the lease information in the 304 prefix pool, then populate it to relay agent, make the state 305 machine on the relay agent keep synchronizing the lease and status 306 of the associated prefix pool with the server. But the solution 307 proposed in this draft is to let relay agent confirm the received 308 status of the prefix pool by itself as per the leases of delegated 309 customer prefixes within it, and build its own lease for the 310 prefix pool. 312 5. Relay Agent Behavior 314 The relay agent who needs the information of prefix pools, must 315 include the associated requested-option-code in Option Request option 316 (OPTION_ORO, 6) to request the Prefix Pool option 317 (OPTION_PREFIX_POOL, [TBD]) from the DHCPv6 server, who maintains the 318 status of the prefix pools associated to the relay agent itself 319 (Figure 1) or its particular customer-facing interface (Figure 2), 320 when receiving the DHCPv6-PD message from clients. The DHCPv6 relay 321 agent can include this Option Request option for the Prefix Pool 322 option in the relay-forward (12) message of SOLICIT (1), REQUEST (3), 323 RENEW(5), REBIND (6) and RELEASE (8). The relay agent may also 324 include the Prefix Pool option with the values of pfx-pool-len and 325 IPv6-prefix to indicate its preference, which the prefix pool the 326 relay agent would like the server to return. 328 The relay agent should include the Interface ID option 329 (OPTION_INTERFACE_ID, 18) so that the DHCPv6 server can identify the 330 relay agent itself or its particular customer-facing interface to 331 which the prefix pool is associated, if the server would not like to 332 use the link-address field specified in the encapsulation of the 333 DHCPv6 relay-forward message to identify the interface of the link on 334 which the clients are located. 336 The relay agent may set up a table for the leases or status of the 337 prefix pools on it as per the delegated customer prefixes within it. 338 The lease of the prefix pools must dynamically set to be the maximum 339 lease of the delegated customer prefixes. If there is no route entry 340 directing to the customer network within the aggregated route 341 associated with the prefix pool, the relay agent shall automatically 342 withdraw the aggregated route. 344 After receiving the Prefix Pool option for the relay agent itself or 345 its particular customer-facing interface in the relay-reply message 346 (13) of REPLY (7) from the DHCPv6 server, the relay agent acting as 347 the PE router shall confirm the status of the prefix pool as per the 348 leases of delegated customer prefixes within it, then add or withdraw 349 the aggregated route entry per the status of the prefix pool. If the 350 status of the prefix pool received and confirmed is 'Active', the 351 relay agent shall add an aggregated route entry in its routing table, 352 if the same entry has not been added in before. If the status of the 353 prefix pool received is 'Released', the relay agent shall withdraw 354 the associated aggregated route entry in its routing table, if the 355 same entry has not been withdrawn before. 357 The relay agent advertises its routing table including the entries of 358 the aggregated routes based on the information of prefix pools when 359 the routing protocol is enabled on its network-facing interface. 361 The Relay Agent (i.e., Requestor) can use the DHCPv6 Bulk Leasequery 362 [RFC5460] to query the binding data of prefix pools in the 'Active' 363 status from the server. After established a TCP connection with the 364 DHCPv6 server, the relay agent must include Query option 365 (OPTION_LQ_QUERY, 44) and set the proper query-type 366 (QUERY_BY_RELAY_ID, QUERY_BY_LINK_ADDRESS, QUERY_BY_REMOTE_ID), link- 367 address and query-options in the LEASEQUERY (14) message. The query 368 options must include Option Request option (OPTION_ORO, 6) to request 369 the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) from the server. 371 6. Server Behavior 373 Per DHCPv6-PD [RFC3633], if the prefix of the customer network 374 requested in relay-forward (12) message of SOLICIT, REQUEST, RENEW, 375 REBIND from the DHCPv6 client (i.e., the RR) has a valid lease, the 376 DHCPv6 server (i.e., the DR) will delegate the prefix with the 377 relevant parameters in the relay-reply (13) message of REPLY. In 378 order to give a meaningful reply, the server has to be able to 379 maintain the binding data of the delegated IPv6 prefixes with the 380 identification of the client. The Interface ID option 381 (OPTION_INTERFACE_ID, 18) nested in the relay-forward message is 382 usually used to identify the access line of the client. 384 After receiving the Option Request option (OPTION_ORO, 6) requesting 385 the Prefix Pool option (OPTION_PREFIX_POOL, [TBD]) in the relay- 386 forward messages of the PD, the server must include the Prefix Pool 387 option with the status indicated for the associated relay agent 388 itself (Figure 1) or its customer-facing interface (Figure 2) in the 389 relay-reply messages if the relay-forward messages received are 390 valid. 392 The server may use the link-address specified in relay-forward 393 message to identify the relay agent itself or its particular 394 customer-facing interface where the prefix pool is associated, but 395 the server has to maintain the binding data of prefix pools in 396 association with these link-addresses. To be more readable, the 397 server can alternatively use the Interface ID option 398 (OPTION_INTERFACE_ID, 18) included in the relay-forward message by 399 the relay agent to identify the relay agent itself (Figure 1) or its 400 particular customer-facing interface (Figure 2) where the prefix pool 401 is associated. In order to give a meaningful reply, the server has 402 to maintain the binding data of prefix pools in association with the 403 information derived from the Interface ID option. 405 Per DHCPv6 [RFC3315], the server shall copy the same Interface ID 406 option received via the relay-forward message into the relay-reply 407 message. 409 If the administrative policy on the DHCPv6 server permits to support 410 route aggregation on the relay agent for some particular prefix, the 411 status of prefix pool can be determined by the delegated prefixes 412 within the associated prefix pool. If there is at least one 413 delegated prefix within the pool that has a valid lease, the server 414 shall set the status of the associated prefix pool to be 'Active'. 415 After the last prefix releasing in the associated prefix pool, the 416 server shall set the status of the associated prefix pool to be 417 'Released'. If the administrative policy on the server does not 418 permit to support route aggregation on the DHCPv6 relay agent, the 419 server shall set the status of the prefix pools always to be 420 'Released'. 422 When the administrator of the server changes the setting to support 423 route aggregation on the relay agent for the particular prefix pool, 424 the status of the prefix pool may change from 'Released' to be 425 'Active' if at least one delegated prefix within the prefix pool has 426 the valid lease. When the administrator of the server changes the 427 setting not to support route aggregation on the relay agent for the 428 particular prefix pool, the status of the prefix pool may change from 429 'Active' to be 'Released' if at least one delegated prefix within the 430 prefix pool has the valid lease. Then the server may send a relay- 431 reply message of RECONFIGURE (10) to initiate immediately a Renew (5) 432 / Reply (7) PD message exchange with Prefix Pool option between one 433 active client and the server. 435 Multiple prefix pools may be associated with the same PE router 436 implementing a DHCPv6 relay agent (Figure 1) or its customer-facing 437 interface (Figure 2) in the binding table on the server. Note that 438 the delegated prefix is only from one prefix pool. 440 After receiving the LEASEQUERY (14) message from the relay agent with 441 the Query option (OPTION_LQ_QUERY, 44) including the Option Request 442 option (OPTION_ORO, 6) to request the Prefix Pool option 443 (OPTION_PREFIX_POOL, [TBD]), the server must include the Client Data 444 options (OPTION_CLIENT_DATA, 45) in the LEASEQUERY-REPLY (15) and 445 LEASEQUERY-DATA (16) message to convey the binding data of the 446 associated prefix pools with the 'Active' status through the 447 established TCP connection per [RFC5460]. Each Client Data option 448 shall contain a Prefix Pool option, and may contain the Interface ID 449 option (OPTION_INTERFACE_ID, 18). In order to be able to provide 450 meaningful replies to different query types, the server has to be 451 able to maintain the relevant association of prefix pools with the 452 RELAY_ID, link addresses or Remote_ID of the relay agent in its 453 binding database. 455 7. Security Considerations 457 Security issues related DHCPv6 are described in section 23 of 458 [RFC3315]. 460 8. IANA Considerations 462 IANA is requested to assign an option code to Option_Prefix_Pool from 463 the "DHCPv6 and DHCPv6 options" registry 464 (http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6- 465 parameters.xml). 467 9. Contributors List 469 Juergen Schoenwaelder 470 Jacobs University Bremen 471 Bremen 472 Germany 474 Email: j.schoenwaelder@jacobs-university.de 476 Tina Tsou 477 Huawei Technologies 478 Santa Clara, CA 479 USA 481 Email: tina.tsou.zouting@huawei.com 483 10. Acknowledgements 485 Thanks to Ralph Droms for the inspiration from his expired draft 486 (RAAN option), to the DHC working group members, Bernie Volz, Ole 487 Troan and Roberta Maglione for the discussion in the mailing list, to 488 Christian Jacquenet for pointing out the draft should cover one more 489 use case of ISP-Customer network where CPE is directly connected to 490 PE, to Sven Ooghe for some revisions in the email review, to 491 Shrinivas Ashok Joshi for pointing out the draft should cover the 492 robust mechanism against the case of reboot, to Adrian Farrel for the 493 orientation guide on this draft in IETF80 at Prague. 495 11. References 497 11.1. Normative References 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, March 1997. 502 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 503 and M. Carney, "Dynamic Host Configuration Protocol for 504 IPv6 (DHCPv6)", RFC 3315, July 2003. 506 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 507 Host Configuration Protocol (DHCP) version 6", RFC 3633, 508 December 2003. 510 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 511 "DHCPv6 Leasequery", RFC 5007, September 2007. 513 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 514 February 2009. 516 11.2. Informative References 518 [BBF TR-177] 519 Broadband Forum, "IPv6 in the context of TR-101, Issue 1", 520 November 2010. 522 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 523 Delegation", RFC 3769, June 2004. 525 Authors' Addresses 527 Leaf Y. Yeh (editor) 528 Huawei Technologies 529 Shenzhen, 530 P. R. China 532 Email: leaf.y.yeh@huawei.com 533 Mohamed Boucadair 534 France Telecom 535 Rennes, 536 France 538 Email: mohamed.boucadair@orange.com 540 Ted Lemon 541 Nominum, Inc 542 USA 544 Email: Ted.Lemon@nominum.com 546 Jie Hu 547 China Telecom 548 Beijing, 549 P. R. China 551 Email: huj@ctbri.com.cn