idnits 2.17.1 draft-xia-ibnemo-icim-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 31, 2016) is 2886 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Y. Xia, Ed. 3 Intended status: Standards Track T. Zhou, Ed. 4 Expires: December 2, 2016 Y. Zhang, Ed. 5 S. Hares 6 Huawei 7 P. Aranda 8 D. Lopez 9 Telefornica 10 J. Crowcroft 11 Cambridge University 12 Y. Zhang 13 China Unicom 14 May 31, 2016 16 Intent Common Information Model 17 draft-xia-ibnemo-icim-02 19 Abstract 21 Intent Common Information Model (ICIM) defines a unified model for 22 expressing different layers' intent whatever role, responsibility, 23 knowledge, etc. This document provides an information model to be 24 inherited and expanded to construct specific intent model in 25 different areas. According to this information model, network intent 26 model is put forward which can satisfy users' need in different 27 layers, such as, end-users, business developers, and network 28 administers. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 2, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Intent Common Information Model Overview . . . . . . . . . . 3 67 2.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Relationships in ICIM . . . . . . . . . . . . . . . . . . 6 69 2.3. Intent and Policy . . . . . . . . . . . . . . . . . . . . 7 70 2.4. Role-based Intent . . . . . . . . . . . . . . . . . . . . 7 71 2.5. Intent and FSM . . . . . . . . . . . . . . . . . . . . . 7 72 3. Intent Modeling . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2. Intent overview . . . . . . . . . . . . . . . . . . . . . 9 75 3.3. Top level intent expression . . . . . . . . . . . . . . . 10 76 3.4. Objects in the network . . . . . . . . . . . . . . . . . 10 77 3.5. Type of result . . . . . . . . . . . . . . . . . . . . . 11 78 3.6. Operation composition . . . . . . . . . . . . . . . . . . 12 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 82 7. Informative References . . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 Network operations have traditionally been designed bottom-up 88 starting with low level device interfaces designed by protocol 89 experts.In order that interfaces could be wildly used by various 90 users, information details are exposed as much as possible. It 91 enables better control of devices, but leaves huge burden of 92 selecting useful information to users without well training. Since 93 the north bound interface (NBI) is used by network users, a more 94 appropriate design is to express user intent and abstract the network 95 from the top down. The intent base NBI expresses what a network 96 service consumer (e.g., application, operator) requires from the 97 network but it does not completely specify or constrain how that 98 service may or should be delivered by the network. The intent is 99 expected to be independent of protocols, network interface styles, 100 vendor features, media attributes, or any other network 101 implementations. 103 Intent Common Information Model (ICIM) specifies a generic model for 104 expressing key components of intent interface and the relationship 105 between these components. This document provides a common model 106 which could be inherited from and expanded to construct specific 107 intent interface in dedicated areas. According to this information 108 model, intent interface in network area can satisfy users' intention 109 in different roles, such as, end-users, business developers, network 110 administers, etc. 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. Intent Common Information Model Overview 120 Intent Common Information Model aims to specify a unified information 121 model which satisfied different areas, scenarios, and other 122 constraints. So, it is a complete and detailed information model to 123 define the constituent elements of intent. However, not all elements 124 need to be present when mapping this model to a specific data model, 125 since some of the elements can be obtained by system automatically. 126 From the overall perspective, construction elements of intent can be 127 described as: 129 -user of intent who author and own this intent 131 -intent content which is a desired purpose and 133 -the specific context which is the background circumstance 134 information. 136 Furthermore, in general, person's intent content usually describes 137 the ultimate state of some objects or applies actions to these 138 objects. So intent content can be abstracted into further: 140 -object which is the target for intent 142 -result which is a desired state and 143 -operation which is the specific actions to achieve a purpose. 145 2.1. Elements 147 2.1.1 Users 149 User is an abstract class which specifies the subject and owner to 150 express the intent. It is a performance of roles in real world, that 151 is, each user serves as a role or a combination of roles actually. 152 For example, end-users, business designers, network administrators 153 are all instances of User class which act as specific roles. When a 154 user is labeled as a role, he will have the desire and requirement to 155 express intent belonged to this role. Owning to different network 156 abstraction views, intent is different for specific user when this 157 information model is applied to specific scenario. 159 Though one user serves as one role in most cases, it is sensible and 160 acceptable that one user serves as multiple roles and intent of these 161 users may involve more functions and huge operation scope. 163 2.1.2 Context 165 Context is an abstraction class which refers to a set of specific 166 background information such as, timer, price, and so on. Context has 167 a huge influence on a person designing a detailed plan or selecting 168 the best program to achieve a purpose. For example, when an 169 enterprise plans to build a dedicated connection between two sites, 170 price and distance will be the context in this scenario. While may 171 not be part of how an entity expresses or executes some intent, it is 172 a factor that must be considered with the expression of intent. 174 2.1.3 Object 176 Object is an abstract class which refers an abstract class which 177 defines some entities affected or managed by intent. For the 178 management, users could manage life cycle of the objects through some 179 concrete operations, such as, create, update, delete, etc. In 180 addition, users could use other specific operations to affect the 181 behavior of managed objects. For example, a business designer want 182 all traffic be filtered by a special firewall. The object of this 183 business designers intent could be the all traffic flowing on a 184 specific network (e.g. L3VPN), and this intent impacts the 185 forwarding behavior of the traffic network. Object is different in 186 specific area. In network area, object is an aggregation class with 187 CustomerFacingNode, Connection and ServiceFlow. For objects, users 188 could construct some specific objects to achieve intent, and it is 189 also allowed for users to assign intent to existing resources which 190 is physical/virtual devices or defined by other ways. 192 2.1.4 Result 194 Result is a type of intent which refers to an final state or 195 something an individual wants to achieve. This type of intent 196 shields difference and diversity of an environment away from the 197 users' intent. The person just describes the final state of objects 198 without worrying about how to achieve it. For example, a result 199 could be that the company accesses any sites on the Internet safely. 200 It just defines a result that ignores technology details, such as, 201 firewall, ACL, and so on. 203 In addition to the expecting state, violation is another special 204 state which has an important status when achieving integral 205 compliance. For example, a typical scenario is that one specific 206 tenant does not want his virtual machines to share a some hypervisor 207 with other tenants. This type of result just shows the undesired 208 state which express users' intent, so this kind of intent should be 209 another type of result. 211 2.1.5 Operation 213 Operation is a type of intent which refers to some specific actions 214 an individual desires to take for realizing the purpose. This type 215 of intent formulates explicit plan to realize a purpose which may 216 take a better control of the whole system. According to the 217 diversity of system support capability, there are large sets of 218 operations for users to take. 220 Generally, operations can be divided into two categories. One is 221 action without condition. For example, create a virtual machine. 222 This kind of operation defines a concrete action which is executed 223 immediately without any trigger. The other is action with condition. 224 For this kind of operations, condition is a trigger for the action. 225 And actions will not be executed immediately until the condition 226 clause is tested to be true. For example, "do load balancing when 227 the utilization of a link exceeds 80%". In this example, 228 "utilization of a link > 80%" is the trigger, and "do load balancing" 229 is the action. Action will not be executed until the trigger is 230 true. Actions are different according to users' role which has 231 different abstraction views. And actions will not be detailed 232 configurations in devices, but high-level and packaged functions 233 which are translated into configurations. For example, the service 234 providers' action "do load balancing" is device independent, and 235 network operators' action may configure load balance pools depending 236 on specific devices. 238 2.2. Relationships in ICIM 240 2.2.1 Relationship between Result and Operation 242 Users are free to express their intent, no matter it is an final 243 result or specific operations in their mind, but there are some 244 relationships between these two basic types of intent. Result refers 245 to an ultimate and relatively permanent status, regardless which ways 246 to maintain it. However, operations specify what kinds of action 247 need to take explicitly, which more focus on temporary or specific 248 behavior to achieve some goal. One typical service scenario is that 249 all links' utilization should not exceed 80%. By way of Result, the 250 intent will be expecting all links' utilizations are smaller than 80% 251 (or avoiding any link' utilization exceeds 80%). By way of 252 Operation, the intent will be if links' utilization exceeds 80%, 253 redirect some flows to other links (or some other actions could 254 achieve this goal). 256 For result, users just need to express the goal without worrying how 257 to implement it in a specific system which allows users to focus on 258 real requirement. To achieve the result, it needs some reasoning 259 mechanisms to transfer it to real executable operations which are 260 supported by specific system. So in a specific scenario, a result 261 can generate a set of concrete operations. For the above example, if 262 user just expresses the result, that is, all links' utilizations are 263 smaller than 80%. The system will choose suitable operations to 264 achieve this status automatically, i.e., expand the capacity of links 265 whose utilization exceed 80%, or redirect flows to other links whose 266 capacities are far less than 80%. 268 2.2.2 Relationship between Object and Operation 270 Operation refers to some specific actions on some objects, so object 271 is the target of an action. In general, any action will include some 272 objects to execute this action. When users want to execute some 273 actions to achieve goals, they may construct the target objects and 274 assign specific actions on them, and it is allowed for users to use 275 existing resources to do some operations. Though object is the 276 target of action, it offers the constraint for optional operations. 277 For example, for a virtual machine, the optional operations are 278 create, delete, migrate, etc. 280 2.2.3 Relationship between Object and Result 282 Result refers to some final state for some objects. This type of 283 intent does not define which specific operations to take, but only 284 express the desired state of objects. So it is independent on 285 objects' concrete capability. For example, intent is all virtual 286 machines' CPU utilization could not exceed 80%. It does not assign 287 specific operations. So reasoning mechanism will choose suitable 288 operations to satisfy this intent, such as, migrate virtual machine 289 or expand it. 291 2.3. Intent and Policy 293 In industry, Policy already has a clear definition, such as in 294 RFC3060. Policy rule consists of an event, a set of conditions and a 295 set of actions. When an event occurs, actions will be taken until 296 condition clauses are evaluated to be true. 298 As mentioned above, intent refers to a purpose in achieving result or 299 performing operation. The intent has a larger scope compared with 300 the policy since Intent can express both result and operation. On 301 one hand if a result is described by intent, there may be no specific 302 action given to show how to achieve this intent. On the other hand, 303 if operation described by intent, conditions of action is optional. 304 Policy is a specific form of operation in intent. 306 2.4. Role-based Intent 308 In an integrated system, roles are divided into several categories 309 according to the division of work, architecture of system, etc. In 310 network system, network abstraction will be quite different in the 311 perspective of each role. So intent has strong dependencies on 312 roles. Intent expressed by different categories of roles will focus 313 on different points and have different intent expression. 315 For example, if an agent is labeled as service provider role, he may 316 just care about the high-level services, such as, security 317 communication. And if he is labeled as network architecture role, he 318 will care about the details of the whole architecture. 320 2.5. Intent and FSM 322 Intent, standing on the perspective of users, expresses intuitive 323 service requirement, including desired network services or means to 324 fulfill network goals. In other words, the Intent model defines a 325 series of FSMs(finite-state machines) and transition between these 326 state machines to implement the managment of service's life cycle. 328 Specifically, each state machine, combining with elements which 329 construct intent, represents a specific state of one or several 330 objects, for example, a normal-work state or exception state of a 331 connectivity service. Both current state(or initial state) and 332 result state(or desired state) are one type of state machines, the 333 main difference between which is that result state is an ultimate 334 state repects users' requirement, otherwise, current state represents 335 a initial state needs to be transited to others states to satisfy 336 users' intent. 338 Operation, including specific actions, represents the transition 339 between current state and result state that describe the state of 340 objects as mentioned above. The transition between service states 341 could be shown as below. 343 operation 344 +-------------------------+ 345 | | 346 +------+------+ +------+-----+ 347 |current state+-----------+result state| 348 +-------------+ +------------+ 349 Figure 1 intent and FSMs 351 Just as mentioned in the section 2.2, operation is the mean to change 352 network service state to fulfill users' intent, namely, the result 353 state. For users, who clearly grasp how to reach result state or 354 have to assgin actions for other reasons, they could descibe specific 355 operations in intent to realize the result. Otherwise, users just 356 need to descibe what's the result or desired state, and the complier 357 system will produces specific operations to achive the result. 359 A typical scenario is the constraint for bandwidth utilization. For 360 user who does not know the ways to adjust bandwidth, he may express 361 his intent with desired state, namely, the result state is bandwidth- 362 utilization<80% and system will choose suitable ways to adjust 363 bandwidth, such as, expansion or changing route. But for users who 364 has experience with network operation, he may express his intent with 365 operaiton, namely, do load balancing if bandwidth-utilization>80%. 366 Both expressiones descibe service state machines and transition, but 367 operation could implement the transition between current state and 368 result state. 370 3. Intent Modeling 372 This section defines the concept and hierarchy of intent, and 373 describes the Intent Common Information Model. 375 3.1. Notation 377 The notation used in this document is adapted from the UML (United 378 Modeling Language). We will use the UML for the intent information 379 modeling. This section listed symbols that will be used in this 380 document for relationships among information models. 382 --> 384 Stands for the association relationship. Association represents the 385 static relationship shared among the objects of two classes. 387 --A 389 Stands for the aggregation relationship. Aggregation is a variant of 390 the "has a" association relationship; aggregation is more specific 391 than association. It is an association that represents a part-whole 392 or part-of relationship. Aggregation can occur when a class is a 393 collection or container of other classes, but the contained classes 394 do not have a strong lifecycle dependency on the container. The 395 contents of the container are not automatically destroyed when the 396 container is. 398 --C 400 Stands for the composition relationship. Composition is a stronger 401 variant of the "has a" association relationship. It is more specific 402 than aggregation. Composition usually has a strong lifecycle 403 dependency between instances of the container class and instances of 404 the contained class. If the container is destroyed, normally every 405 instance that it contains is destroyed as well. 407 --G 409 Stands for the generalization relationship. The Generalization 410 indicates that one of the two related classes (the subclass) is 411 considered to be a specialized form of the other (the super type) and 412 the super class is considered a 'Generalization' of the subclass. In 413 practice, this means that any instance of the subtype is also an 414 instance of the super class. 416 3.2. Intent overview 418 In general, intent is one's specific mental activity, so it strongly 419 depends on the subject. Different users may have different intent. 420 In addition, context, omitted usually, is an important factor when 421 achieving purpose, which offers necessary background information to 422 impact the decision. It illustrates the overview of the intent. 423 Figure 2 indicates that the user has intent in some context. For 424 example, an enterprise wants to block all http traffic in work time. 425 In this intent, the user is the enterprise, the intent is to block 426 all http traffic in the work hours, and the context includes the 427 definition of the "enterprise" and the "work hours". 429 +------+ has +------+ in +-------+ 430 | user +---->+intent+---->+context| 431 +------+ +------+ +-------+ 432 Figure 2 general prescription for intent 434 3.3. Top level intent expression 436 In Cambridge Dictionaries, the definition of "intent" is the fact 437 that you want and plan to do something. So, in general, intent 438 refers to an agent's purpose on getting the result or performing some 439 specific operation. In specific areas, these results or operations 440 will relate to some objects. Figure 3 describes the general 441 expression of intent. 443 +--------+ 444 | intent | 445 +-C-A-A--+ 446 | | | 447 +-----------+ | +-------------+ 448 | | | 449 | | | 450 +---+---+ +--+---+ +-----+-----+ 451 | object| |result| | operation | 452 +-------+ +------+ +-----------+ 453 Figure 3 intent expression 455 One type of intent is to express key operations that a user wants to 456 execute. The underlying intent system can generate a complete 457 operation list from user's request. The other type of intent is to 458 express the result or state without dictating any operations. 460 For example, intent of a user may be a result without defining how to 461 realize it, such as, requiring security communication between two 462 sites, or dictate some detailed operations in order to achieve a 463 purpose, such as, filtering all traffics by firewall between these 464 two sites. 466 3.4. Objects in the network 468 Object is an abstraction class which can be inherited from and 469 expanded in different area. It, cared about by users, represents the 470 target of result and operations. In network area, the object, i.e. 471 the target of intent, can be generalized into 472 CustomerFacingNode(CFN), Connection and ServiceFlow, as shown in 473 Figure 4. 475 +------------------+ 476 +---+CustomerFacingNode| 477 | +------------------+ 478 +------+ | 479 | +G+--+ +----------+ 480 |Object+G+------+Connection| 481 | +G+--+ +----------+ 482 +------+ | 483 | +-----------+ 484 +---+ServiceFlow| 485 +-----------+ 486 Figure 4 common objects in network area 488 The CustomerFacingNode represents the functions a user-facing network 489 node may provide in a network such as network services, forwarding 490 functions (firewall, load balancer, virtual router, and others), or a 491 group of network elements. A group of network elements can be a 492 subnet, an autonomous system, or a confederation of autonomous 493 systems. 495 The Connection describes the link resources between two CFNs. These 496 link resources construct the foundation of communications between 497 different CFNs. User could take connection as physical link, and 498 assign bandwidth on it. 500 The ServiceFlow refers to the traffic in network which describes data 501 packets have some certain common characters. ServiceFlow model 502 describes the connectivity in virtual network, namely, if users want 503 to describe the communications between CFNs without direct 504 connection, they have to define the service flow and assign operation 505 to allow the service flow. 507 3.5. Type of result 509 Result refers to the final state which is expected or avoided. 510 Figure 5 describes two types of result. Both of the results just 511 show the performance of some objects, without caring about how to 512 reach them. 514 Result could be expressed as a set of logic clause connected with 515 propositional literals including AND, OR and NOT. The logic clause 516 could be described as an expression with relational operators, such 517 as equal, greater-than, less-than, belong-to. 519 With this model, users could express the desired state as an 520 expression. System will resolve the expression and seek ways to make 521 it true. The result will be achieved when the expression is 522 evaluated to be true. The typical examples are shown as follows: 524 - For example, a user may express an intent as the network link 525 utilization must less than 80%. This expression is a type of result 526 which describes an expected state. The left operand is the 527 utilization of all links, the right operand is 80%, and the operator 528 is less-than. 530 - Another example is an enterprise wants the development team and 531 sales team not to share a common link. In this intent, the left 532 operand is the union of the link set of development team occupied and 533 the link set of sales team occupied. The operation will be equal, 534 and the right operator is an empty set. 536 Though a unified information model for the Result is proposed in 537 here, it is still a preliminary version which just expresses the 538 basic components. The formalization and standardization are still 539 open issues need to be studied further. More comprehensive and 540 detailed manifestations will be added in the next version. 542 +--------+ 543 | result | 544 +--G-G---+ 545 | | 546 +-----+ +-----+ 547 | | 548 +---+----+ +---+---+ 549 | expect | | avoid | 550 +--------+ +-------+ 551 Figure 5 expression of Result 553 3.6. Operation composition 555 Operation refers to some specific actions in order to achieve some 556 purposes. An operation must have some actions. However, if 557 condition and constraint can be optionally defined in operations, it 558 depends on specific scenario and users' requirement. Once a 559 condition is involved in operation, actions will not be executed 560 immediately until condition is true. In additional, constraint 561 restricts action itself or the scope of action. 563 For example, redirect traffic to back-up link when the utilization of 564 current link exceeds 80%, except the flow from VIP user. In this 565 scenario, the condition is link utilization exceeds 80%, the action 566 is redirect traffic, and the constraint is VIP flow could not be 567 redirected. 569 +---------+ 570 |operation| 571 +--A-C-A--+ 572 | | | 573 +---------+ | +------------+ 574 | | | 575 | | | 576 +----+----+ +--+---+ +-----+----+ 577 |condition| |action| |constraint| 578 +---------+ +------+ +----------+ 579 Figure 6 composition of operation 581 4. Security Considerations 583 TBD 585 5. IANA Considerations 587 This draft includes no request to IANA. 589 6. Acknowledgements 591 The authors would like to thanks the valuable comments made by Wei 592 Cao, Sheng Jiang, Zhigang Ji, Xuewei Wang, Shixing Liu, Yan Zhang. 594 7. Informative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 Authors' Addresses 601 Yinben Xia 602 Huawei Technologies Co., Ltd 603 Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District 604 Beijing 100095 605 China 607 Email: xiayinben@huawei.com 609 Tianran Zhou 610 Huawei Technologies Co., Ltd 611 Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District 612 Beijing 100095 613 China 615 Email: zhoutianran@huawei.com 616 Yali Zhang 617 Huawei Technologies Co., Ltd 618 Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District 619 Beijing 100095 620 China 622 Email: zhangyali369@huawei.com 624 Susan Hares 625 Huawei Technologies Co., Ltd 626 7453 Hickory Hill Saline 627 MI 48176 628 USA 630 Email: shares@ndzh.com 632 Pedro Andres Aranda 633 Telefornica I+D 634 Don Ramon de la Cruz, 82 Street Madrid 635 28006 636 Spain 638 Email: pedroa.aranda@telefonica.com 640 Diego R. Lopez 641 Telefornica I+D 642 Don Ramon de la Cruz, 82 Street Madrid 643 28006 644 Spain 646 Email: diego.r.lopez@telefonica.com 648 Jon Crowcroft 649 University of Cambridge Computer Laboratory 650 William Gates Building, 15 JJ Thomson Avenue Cambridge 651 CB3 0FD UK 653 Email: jon.crowcroft@cl.cam.ac.uk 654 Yan Zhang 655 China Unicom P.R. 656 China 658 Email: zhangy1036@chinaunicom.cn