idnits 2.17.1 draft-madhavan-alto-subscription-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-alto-deployments]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 350 has weird spacing: '...CostMap cos...' == 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 (February 1, 2013) is 4074 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'OPTIONAL' is mentioned on line 352, but not defined == Missing Reference: 'TODO' is mentioned on line 522, but not defined == Unused Reference: 'RFC2119' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-reqs' is defined on line 613, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-04 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-12 == Outdated reference: A later version (-03) exists of draft-lee-alto-ext-dc-resource-00 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Madhavan 3 Internet-Draft R. Nandiraju 4 Intended status: Informational Huawei Technologies 5 Expires: August 1, 2013 February 1, 2013 7 ALTO Subscription 8 draft-madhavan-alto-subscription-01 10 Abstract 12 The specification of the ALTO protocol uses map based approaches 13 assuming that the information provided is static for a longer period 14 of time. But in some cases network operators reallocate IP subnets 15 from time to time which in turn changes the mapping partitions[I- 16 D.ietf-alto-deployments]. Since the ALTO clients are unaware of the 17 map information changes, clients need to query the servers for every 18 service request and many such requests are redundant because the 19 information was not changed. The purpose of this memo is to propose 20 a mechanism where ALTO clients can subscribe for event notifications 21 from the server 23 Status of this Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 2, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. ContactAddr . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Subscription and Notification Service . . . . . . . . . . . . 5 65 7.1. Requesting a Subscription . . . . . . . . . . . . . . . . 5 66 7.1.1. Input Parameters . . . . . . . . . . . . . . . . . . . 6 67 7.2. Refreshing of Subscriptions . . . . . . . . . . . . . . . 7 68 7.3. Notifier Subscription Handling . . . . . . . . . . . . . . 7 69 7.3.1. Response . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.4. Notifier Notification behavior . . . . . . . . . . . . . . 8 71 7.4.1. Input Parameters . . . . . . . . . . . . . . . . . . . 8 72 7.5. Subscriber Notification handling . . . . . . . . . . . . . 9 73 7.6. Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 9 74 7.7. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8. Detecting support for Subscription Service . . . . . . . . . . 11 76 8.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9. Transport Considerations . . . . . . . . . . . . . . . . . . . 14 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 11.1. application/alto-* Media Types . . . . . . . . . . . . . . 14 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 The goal of Application-Layer Traffic Optimization (ALTO) is to 90 provide guidance to applications, which have to select one or several 91 hosts from a set of candidates, that are able to provide a desired 92 resource [RFC5693]. The requirements for ALTO are itemized in 93 I-D.ietf-alto-reqs. ALTO is realized by a client-server 94 protocol.ALTO clients send queries to ALTO servers, in order to 95 solicit guidance. 97 ALTO clients needs to query the ALTO server for cost map and network 98 map information to select one or several hosts from a set of 99 candidates. Network Maps may be stable for a longer time but changes 100 whenever the service provider reallocates IP subnets. [I-D.ietf- 101 alto-deployments] 103 This memo defines a mechanism for ALTO clients to subscribe to the 104 ALTO server and get informed of a map information change. The server 105 MAY send only the changed map information even if clients subscribe 106 for complete information. 108 2. Problem Statement 110 Case 1: ISPs reallocate IPv4 subnets within their infrastructure from 111 time to time, partly to ensure the efficient usage of IPv4 addresses. 112 The frequency of these "renumbering events" depend on the growth in 113 number of subscribers and the availability of address space within 114 the ISP. In P2P networks, if this information is shared to trackers, 115 then it can help the trackers to efficiently localize P2P traffic. 117 Case 2: In i2aex, there are use cases for CDN and inter DC data 118 transfer which need notifications of changed information between the 119 ALTO clients and servers [I-D.seedorf-i2aex-alto-cdni-perpective] 120 [I-D.lee-alto-ext-dc-resource] 122 Case 3: Notification based mechanims provide strong cache consistency 123 for ALTO caches 124 [http://www.ietf.org/proceedings/83/slides/slides-83-alto-1.pdf] 126 3. Protocol Structure 128 The ALTO Protocol uses a simple extensible framework to convey 129 network information. In the general framework, the ALTO protocol 130 will convey properties on both Network Locations and the paths 131 between Network Locations.[I-D.ietf-alto-protocol]. 133 The Map filtering and endpoint cost services can be extended to 134 include the map level and subset level expiration time. This memo 135 also extends the ALTO information services to include the 136 subscription and notification service. Any node can transmit a 137 notification through HTTP to any other node for the changes in 138 subscribed events. The framework also provides mechanisms for 139 subscriptions to be done for full maps or subset of the maps 140 available in the Map service. 142 .-------------------------------------------------------------------. 143 | | 144 |.--------..-------------------------------------------------------.| 145 || || ALTO Info Services || 146 || || .-----------. .----------. .----------..-------------.|| 147 || || | Map | | Endpoint | | Endpoint || Subscription||| 148 || || | Filtering | | Property | | Cost || and ||| 149 || || | | | | | || Notification||| 150 || || | | | | | || Service ||| 151 || || | Service | | Service | | Service || ||| 152 || Server || `-----------' `----------' `----------'`-------------'|| 153 || Info. || .-------------------------------------. || 154 || Service|| | Map Service | || 155 || || | .-------------. .--------------. | || 156 || || | | Network Map | | Cost Map | | || 157 || || | `-------------' `--------------' | || 158 || || `-------------------------------------' || 159 |`--------'`-------------------------------------------------------'| 160 | | 161 `-------------------------------------------------------------------' 163 Figure 1: ALTO Protocol Structure 165 4. Overall Operation 167 The overall operation is based on the ALTO client querying the map 168 information. The ALTO server sends the map information providing 169 details of full or subset level expiration. Clients can subcsribe 170 for map information changes. ALTO server sends notifcations for the 171 map information based on the subscription 173 5. Definitions 175 Event:Any change in a resource that can trigger a notification 177 Subscription:An established relationship in which a resource has 178 indicated interest in certain event 179 Subscriber:A subscriber is an ALTO node that initiates a subscription 180 with a subscription server 182 Notification:Notification is the mechanism by which notifier nodes 183 sends changed events information to the subsctiber 185 Notifier:A notifier is an ALTO node which generates Notification 186 messages for the purpose of notifying subscribers of the state of a 187 resource. 189 6. ALTO Types 191 This section details the format for particular data values used for 192 ALTO Subscription framework. Base types defined by I-D.ietf-alto- 193 protocol are used by this memo with some extensions listed below. 195 6.1. ContactAddr 197 The ALTO subscription framework requires the client nodes to provide 198 the contact information which includes the transport tuple details so 199 that server can send notification. These connections may be 200 persistent. 202 ContactAddr is defined as: 203 object { 204 EndpointAddr addr; 205 JSONInteger port; 206 } ContactAddr; 208 7. Subscription and Notification Service 210 The Subcription service allows ALTO clients to subscribe to events so 211 that ALTO server can return full maps or subset of the full maps 212 available in the Map service. On event changes, ALTO server sends 213 notifications for the changed events. 215 7.1. Requesting a Subscription 217 When a subscriber wishes to subscribe to a particular state for a 218 resource, it forms a HTTP POST message.This POST message will be 219 confirmed with a final message, 200 OK message indicating that the 220 subscription is accepted and notification message will be sent 221 immediately. 223 The framework allows entities to subscribe full or subset of full 224 maps provided by the Map service.For example ALTO clients can 225 subscribe for complete maps like NetworkMap, CostMaps or also for 226 subsets like NetworkMapFilter, CostMapFilter or Endpoint services. 227 Subscription request MUST carry "eventtype", "expires" value, 228 "contactaddr" parameters encoded in the JSON object and sent as 229 payload.The "eventtype" indicates what type of events subscription is 230 required.The "expires" key indicates the actual duration for which 231 the subscription will remain active. 233 Subscribers need to provide "contactaddr" in the first subscription 234 message which will be used by server nodes to send notification 235 messages. 237 Non-2xx final response indicates that no subscription is created and 238 no notification messages will be sent. 240 7.1.1. Input Parameters 242 Input parameters are supplied in the entity body of the HTTP POST 243 request. This document specifies the input parameters with a data 244 format indicated by a a media type "application/ 245 alto-subscribeinput+json", which is a JSON object of SubscribeInput: 247 object { 248 JSONString event-types<0....*>; 249 JSONInteger expires; 250 ContactAddr [AddressType]<0..*>; 251 ReqFilteredNetworkMap networkfiltermap; [OPTIONAL] 252 ReqFilteredCostMap costfiltermap; [OPTIONAL] 253 ReqEndpointProp endpointprop; [OPTIONAL] 254 ReqEndpointCostMap endpointcostmap; [OPTIONAL] 255 } SubscribeInput; 257 with members: 259 event-types: List of event types for which subcsription needs to be 260 done. This can be "NetworkMap", "CostMap", "NetworkMapFilter", 261 "CostMapFilter", "endpointprop", "endpointcost" strings. NetworkMap 262 and CostMap events subscrobes for complete information and rest of 263 the event types handles subsets. 265 expires: The expires value indicates the lifetime of the 266 subscription. 268 contactaddr: Used by the notifier to contact the subscriber for 269 sending notification details. 271 All the objects are optional and needs to be added based on the 272 eventtype parameter. Refer I-D.ietf-alto-protocol for 273 ReqFilteredNetworkMap, ReqFilteredCostMap, ReqEndpointProp and 274 ReqEndpointCostMap JSON object definitions. 276 7.2. Refreshing of Subscriptions 278 Subscriber can send refresh requests before a subscription expires by 279 sending HTTP POST message with the same event and subscrid parameter 280 returned in 200 OK message.The subscrid parameter is used to 281 differentiate multiple subscriptions from the same node. 283 If a request to refresh a subscription receives a "404" response, 284 this indicates that the subscription has already been terminated. 286 7.3. Notifier Subscription Handling 288 The Notifier should check that the event specified is understood. If 289 not, notifier should send "503 Service Unavailable" response to 290 indicate that the specified event is not understood. 292 If the event is understood, notifier creates a subscription and 293 stores the "contactaddr", event-type and expires information.Notifier 294 returns a "200 OK" message which indicates that the subscription is 295 succesful. 200 OK reponse message contains the "event" information,a 296 unique "subscrid" parameter and "expires" value. The subscrid 297 parameter is used to differentiate multiple subscriptions. 299 7.3.1. Response 301 Input parameters are supplied in the entity body of the 200 OK 302 message. This document specifies the input parameters with a data 303 format indicated by a a media type "application/ 304 alto-subscriptiondata+json". 306 object { 307 JSONString subscrid; 308 JSONInteger expires; 309 JSONString event-types<0....*>; 310 } SubcriptionData; 312 with members: 314 subscrid: This id is sent by notifier and is used to uniquely 315 identify subscription. Refresh subscriptions and notifications MUST 316 carry this id 318 event-types: This should be the same received in the subscription 319 request 321 7.4. Notifier Notification behavior 323 Notifier indicates a change in the subscribed state by sending a HTTP 324 POST message with resource information, event, "substate" and 325 "subscrid" parameter.The resource information can be NetworkMap, 326 CostMap, NetworkMapFilter,CostMapFilter or EndPoint Service 327 information. The "substate" refers to the subscription state which 328 can be "active" or "terminated". The "substate" indicates the 329 subscription state maintained by the notifier. 331 If the value of the "substate" is active, the notifier should include 332 an expires value indicating the time remaining for the subscription. 334 If the value of the "substate" is terminated, the notifier may 335 include a "reason" value. 337 7.4.1. Input Parameters 339 Input parameters are supplied in the entity body of the HTTP POST 340 request. This document specifies the input parameters with a data 341 format indicated by a a media type "application/ 342 alto-notificationdata+json". 344 object { 345 JSONString event-type<0....*>; 346 JSONString subscrid; 347 JSONString substate; 348 JSONInteger expires; 349 InfoResourceNetworkMap networkmap; [OPTIONAL] 350 InfoResourceCostMap costmap; [OPTIONAL] 351 InfoResourceEndpointProperty endpointprop; [OPTIONAL] 352 InfoResourceEndpointCostMap endpointcostmap; [OPTIONAL] 353 } NotifitionData; 355 with members: 357 substate: Indicates the subscription state maintained by the server 359 expires: Indicates the time remaining for the subscription identified 360 by subscrid 362 All the objects are optional and needs to be added based on the 363 eventtype parameter. Refer I-D.ietf-alto-protocol for 364 InfoResourceNetworkMap, InfoResourceCostMap, 365 InfoResourceEndpointProperty and InfoResourceEndpointCostMap JSON 366 object definitions. 368 7.5. Subscriber Notification handling 370 Subscriber should check the subscrid returned in the notification 371 message to check whether this is an outstanding subscription. If 372 not, it MUST return "404 Not Found" response message. 374 If the substate is active, it means that the subscription is active 375 and hence can check the expires value. Subscriber can send refresh 376 requests if required. 378 7.6. Unsubscribing 380 Unsubscription is done by sending HTTP POST message with uri as 381 example.com/unsubscribe and payload containing the "subscrid" which 382 needs to be terminated. 384 7.7. Example 386 An ALTO node [P2P Tracker] queries the ALTO server and contacts the 387 peer for service. Node wants to subscribe for resource state changes 388 [Filtered Network Map].Refreshing of the subscription is done and is 389 terminated later using unsubscribe option.In this example, the ALTO 390 Server provides subscription, notification and unsubscribe service 391 via a separate subdomain, "custom.alto.example.com". 393 POST /subscription HTTP/1.1 394 Host: custom.alto.example.com 395 Content-Length: [TODO] 396 Content-Type: alto-subscribeinput+json 397 Accept: application/alto-subscriptiondata+json, 398 application/alto-error+json 400 { 401 "event-types": ["NetworkMapFilter"], 402 "expires": 3600, 403 { 404 "ipv4": [ 405 "addr": "192.0.2.0", 406 "port": 5828 407 ] 408 }, 409 { 410 "pids": [ "PID1", "PID2" ] 411 } 412 } 414 HTTP/1.1 200 OK 415 Content-Length: [TODO] 416 Content-Type: application/alto-subscriptiondata+json 418 { 419 "subscrid": "1223subsrandstr", 420 "expires" : 3600, 421 "event-types": ["NetworkMapFilter"] 422 } 424 Change in the resource state is notified using notification message. 426 POST /notification HTTP/1.1 427 Host: custom.alto.example.com 428 Content-Length: [TODO] 429 Content-Type: application/alto-notificationdata+json 430 Accept: application/alto-error+json 432 { 433 "event-types": ["NetworkMapFilter"], 434 "subscrid": "1223subsrandstr", 435 "substate": "active", 436 "expires": "3600", 437 { 438 "meta" : {}, 439 "data" : { 440 "map-vtag" : "1266506139", 441 "map" : { 442 "PID1" : { 443 "ipv4" : [ 444 "192.0.2.0/24", 445 "198.51.100.0/25" 446 ] 447 }, 448 "PID2" : { 449 "ipv4" : [ 450 "198.51.100.128/25" 451 ] 452 }, 453 "PID3" : { 454 "ipv4" : [ 455 "0.0.0.0/0" 456 ], 457 "ipv6" : [ 458 "::/0" 459 ] 460 } 461 } 462 } 463 } 465 } 467 HTTP/1.1 200 OK 469 Node refreshes the subscription. 471 POST /unsubscribe HTTP/1.1 472 Host: alto.example.com 473 Accept: application/alto-error+json 474 Content-Type: application/alto-subscriptiondata+json 476 { 477 "subscrid": "1223subsrandstr", 478 "expires" : 3600, 479 "event-types": ["NetworkMapFilter"] 480 } 482 HTTP/1.1 200 OK 484 Node terminates the subscription 486 POST /unsubscribe HTTP/1.1 487 Host: alto.example.com 488 Accept: application/alto-error+json 489 Content-Type: application/alto-subscriptiondata+json 491 { 492 "subscrid": "1223subsrandstr", 493 "expires" : 0, 494 "event-types": ["NetworkMapFilter"] 495 } 497 HTTP/1.1 200 OK 499 8. Detecting support for Subscription Service 501 An Information Resource Directory indicates to ALTO Clients which 502 Information Resources are made available by an ALTO Server[I-D.ietf- 503 alto-protocol]. The Information Resource Directory defined by 504 I-D.ietf-alto-protocol will be extended to add new directory entries 505 for Subscription and Unsubscription service. 507 The media-types mentions the list of all media types of information 508 resources which will be sent by the Notifier. 510 8.1. Example 512 The following is an example Information Resource Directory returned 513 by an ALTO Server. In this example, the ALTO Server provides 514 subscription, notification and unsubscribe service via a separate 515 subdomain, "custom.alto.example.com". 517 GET /directory HTTP/1.1 518 Host: alto.example.com 519 Accept: application/alto-directory+json,application/alto-error+json 521 HTTP/1.1 200 OK 522 Content-Length: [TODO] 523 Content-Type: application/alto-directory+json 525 { 526 "resources" : [ 527 { 528 "uri" : "http://alto.example.com/serverinfo", 529 "media-types" : [ "application/alto-serverinfo+json" ] 530 }, { 531 "uri" : "http://alto.example.com/networkmap", 532 "media-types" : [ "application/alto-networkmap+json" ] 533 }, { 534 "uri" : "http://alto.example.com/subscription", 535 "media-types" : [ 536 "alto-subscriptiondata+json" 537 ], 538 "accepts" : [ 539 "application/alto-networkmapfilter+json", 540 "application/alto-costmapfilter+json", 541 "application/alto-endpointpropparams+json", 542 "application/alto-endpointcostparams+json" 543 ] 544 },{ 545 "uri" : "http://alto.example.com/notification", 546 "media-types" : [ 547 "application/alto-networkmap+json", 548 "application/alto-costmap+json", 549 "application/alto-endpointprop+json", 550 "application/alto-endpointcost+json" 551 ], 552 "accepts" : [ 553 "application/alto-networkmapfilter+json", 554 "application/alto-costmapfilter+json", 555 "application/alto-endpointpropparams+json", 556 "application/alto-endpointcostparams+json" 557 ] 558 },{ 559 "uri" : "http://alto.example.com/unsubscribe" 560 } 561 ] 562 } 564 9. Transport Considerations 566 If subscription mechanism needs to be used the ALTO nodes MUST work 567 as peers. 569 Input parameters and responses are encoded in the HTTP request's 570 entity body, and the request uses the HTTP POST method. 572 10. Acknowledgements 574 11. IANA Considerations 576 11.1. application/alto-* Media Types 578 This document requests the registration of multiple media types, 579 listed in Table 1. 581 +-------------+----------------------------+---------------+ 582 | Type | Subtype | Specification | 583 +-------------+----------------------------+---------------+ 584 | application | alto-subscribeinput+json | Section 6.1.1 | 585 | application | alto-subscriptiondata+json | Section 6.4.1 | 586 | application | alto-notificationdata+json | Section 6.5.1 | 587 +-------------+----------------------------+---------------+ 589 Table 1 591 12. Security Considerations 593 TBD 595 13. References 597 13.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 13.2. Informative References 604 [I-D.ietf-alto-deployments] 605 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO 606 Deployment Considerations", draft-ietf-alto-deployments-04 607 (work in progress), March 2012. 609 [I-D.ietf-alto-protocol] 610 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 611 draft-ietf-alto-protocol-12 (work in progress), July 2012. 613 [I-D.ietf-alto-reqs] 614 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 615 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 616 Requirements", draft-ietf-alto-reqs-16 (work in progress), 617 June 2012. 619 [I-D.lee-alto-ext-dc-resource] 620 Lee, Y., Bernstein, G., Madhavan, S., and D. Dhody, "ALTO 621 Extensions for Collecting Data Center Resource 622 Information", draft-lee-alto-ext-dc-resource-00 (work in 623 progress), July 2012. 625 [I-D.seedorf-i2aex-alto-cdni-perpective] 626 Seedorf, J., "Infrastructure-to-application information 627 exposure from an ALTO-CDNI Perspective", 628 draft-seedorf-i2aex-alto-cdni-perpective-00 (work in 629 progress), March 2012. 631 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 632 Optimization (ALTO) Problem Statement", RFC 5693, 633 October 2009. 635 Authors' Addresses 637 Sreekanth Madhavan 638 Huawei Technologies 639 Bangalore, 640 India 642 Phone: 643 Email: sreekanth.madhavan@huawei.com 645 Nandiraju Ravishankar 646 Huawei Technologies 647 Bangalore, 648 India 650 Phone: 651 Email: ravi.nandiraju@huawei.com