idnits 2.17.1 draft-ietf-6tisch-coap-00.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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.wang-6tisch-6top-interface], [IEEE802154e]), 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 -- The document date (May 6, 2014) is 3636 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: 'IEEE802154e' is mentioned on line 568, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH R. Sudhaakar, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track P. Zand 5 Expires: November 7, 2014 University of Twente 6 May 6, 2014 8 6TiSCH Resource Management and Interaction using CoAP 9 draft-ietf-6tisch-coap-00 11 Abstract 13 The [IEEE802154e] standardizes the TSCH mode of operation and defines 14 the mechanisms for layer 2 communication between conforming devices. 15 6top defines a set of commands to monitor and manage the TSCH 16 schedule. To realize the full functionality of sensor networks and 17 allow their adoption and use in real applications we need additional 18 mechanisms. Specifically, we need to define how to interact with 19 6top, control and modify schedules, monitor parameters etc. Higher 20 layers monitoring and management entities are then able to use these 21 capabilities to create feedback loops. Although, there have been 22 many custom implementations of such feedback loops between the 23 routing, transport and MAC layers in sensor network deployments, 24 there has been a lack of standards based approaches. The goal of the 25 memo is to define the messaging between monitoring and management 26 entities and the 6top layer and a mapping to the 6top commands. The 27 document also presents a particular implementation of the generic 28 data model specified in [I-D.wang-6tisch-6top-interface] based on 29 CoAP and CBOR. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 7, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Scope of the document . . . . . . . . . . . . . . . . . . . . 3 68 4. Data Model definition for CoAP . . . . . . . . . . . . . . . 4 69 4.1. Naming Convention for URI schemes . . . . . . . . . . . . 4 70 4.2. Convention for accessing URIs . . . . . . . . . . . . . . 4 71 4.3. 6TiSCH Resources . . . . . . . . . . . . . . . . . . . . 5 72 4.3.1. Management Resources . . . . . . . . . . . . . . . . 5 73 4.3.2. Informational Resources . . . . . . . . . . . . . . . 7 74 4.3.3. Message Formats . . . . . . . . . . . . . . . . . . . 7 75 4.3.4. Extensible Resources . . . . . . . . . . . . . . . . 9 76 4.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.4.1. Request-Response . . . . . . . . . . . . . . . . . . 10 78 4.4.2. Publish-Subscribe . . . . . . . . . . . . . . . . . . 11 79 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 5.2. Informative References . . . . . . . . . . . . . . . . . 12 82 5.3. External Informative References . . . . . . . . . . . . . 13 83 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Requirements notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Introduction 94 The 6TiSCH Operation Sublayer (6top) [I-D.wang-6tisch-6top-interface] 95 describes the main commands provided to higher layers that allow them 96 to build TSCH schedules, make routing decisions, perform TSCH 97 configuration and control procedures and supports centralized and 98 decentralized scheduling policies among other functionalities. 99 However, there is still a need for specifying the methods, including 100 message exchanges and message formats that higher layers use to 101 invoke these command described by 6top. 103 +------------------------------------+ 104 | Higher Layers | 105 +------------------------------------+ 106 | CoAP - Resource Management | 107 | and Interaction | 108 +------------------------------------+ 109 | 6top | 110 +------------------------------------+ 111 | 802.15.4e TSCH | 112 +------------------------------------+ 114 Figure 1: Logical positioning of layers 116 In order to have an wide impact we need to be able to interoperate 117 with any protocol that may be used by the network layer. This 118 documents aims at defining the message exchanges and the formats of 119 the messages that the network layer uses to interact with the 6top 120 sub-layer. The messaging scheme defined in this document is aimed 121 for use between 6top nodes and higher layer management entities as 122 well as between 6top nodes. 124 This document also specifies an implementation of this generic 125 message exchange and data model using CoAP as the transport 126 mechanism. 128 3. Scope of the document 130 This draft defines the communication mechanism between PCE and 6top 131 nodes using COAP. We use the generic YANG data model defined in 132 [I-D.wang-6tisch-6top-interface] to define the various CoAP messages 133 and payloads. The payload used CBOR for the encoding format. The 134 document also defines the URIs that used to identify the resources 135 exposed by 6top. 137 This document also defines how users can install custom resources 138 that allow them to extend the basic resource exposed by 6top. 140 4. Data Model definition for CoAP 142 4.1. Naming Convention for URI schemes 144 Universal Resource Identifiers (URIs) help us uniquely identify the 145 various commands and parameters that 6top exposes to the higher 146 layers. We use the basic URI naming conventions and terminology 147 specified in [RFC3986]. Specifically, the terms, 'scheme', 148 'authority', 'path', 'query' are used as defined in the [RFC3986]. 150 The following provides the guidelines that are followed in this draft 151 to name the URIs that identify the resources exposed by 6top. 153 1. All URIs naming 6top resources MUST use the 'coap' scheme 155 2. The authority MUST have the username '6top' and the IP address of 156 6top node 158 3. The root path MUST always start with '6t' 160 4. Each component of the path SHOULD be of minimum possible length 161 while being self descriptive. 163 5. Typographical conventions as described in A SHOULD be followed 165 These guidelines MUST be followed by users who install extensible 166 resources. It SHOULD be followed for future extensions of the data 167 model in order to provide consistency. 169 4.2. Convention for accessing URIs 171 We use the GET, POST and DELETE methods described by CoAP. These 172 methods MUST be used in accordance with their definition in Sec. 5.8 173 of [I-D.ietf-core-coap]. We have no need for the PUT method as the 174 functionality of the POST method can be used for all situations that 175 need updating or modification of a resource. The CoAP methods are 176 mapped to 6top commands as shown in the figure below. 178 +-------------+--------------+-------------------------+ 179 | CoAP method | 6top command | Description | 180 +-------------+--------------+-------------------------+ 181 | GET | READ | Retrieves 6top resources| 182 +-------------+--------------+-------------------------+ 183 | POST | CREATE / | Creates/Updates a new | 184 | | UPDATE | entry | 185 +-------------+--------------+-------------------------+ 186 | DELETE | DELETE | Deletes an entry | 187 +-------------+--------------+-------------------------+ 188 | POST | CONFIGURE | Configures a setting | 189 +-------------+--------------+-------------------------+ 191 Figure 2: Mapping between CoAP methods and 6top commands 193 The GET method may use queries to allow higher layer entities to 194 perform conditional GETs or filter the results of a GET on resource 195 that is a collection. 197 The POST method is used in all situations where an argument needs to 198 be passed to the 6top layer. The Content-Type option is set to 199 'application/cbor'. The payload is encoded using CBOR format as 200 described in [I-D.bormann-cbor]. 202 The DELETE method is used to invoke the 6top DELETE command on a 203 particular resource. 205 The GET method may use queries to allow higher layer entities to 206 perform conditional GETs or filter the results of a GET on resource 207 that is a collection. 209 4.3. 6TiSCH Resources 211 Management resources are classified as resources to which a higher 212 layer entity may create, update or delete. They are typically used 213 to create schedules, identify time sources that TSCH needs. They are 214 the means to close the control loop between TSCH and higher layers. 216 Informational resources are classified as resources to which a higher 217 layer entity typically has only READ access. They are typically used 218 to monitor operational parameters of TSCH and the values used as 219 input to routing algorithms and other mechanisms. 221 4.3.1. Management Resources 223 All the attributes in the management resources have the Read/Write 224 accessibility. The following table lists the 6top management 225 resources and the related URI paths. 227 +-------------+-----------------+---------------+ 228 | Name | Accessibility | URI path | 229 | | 6top Commands | | 230 +-------------+-----------------+---------------+ 231 | Neighbor | CREATE/READ/ | 6t/Neighbor | 232 | List | DELETE/UPDATE | | 233 +-------------+-----------------+---------------+ 234 | slotframe | CREATE/READ/ | 6t/slotframe | 235 | List | DELETE/UPDATE | | 236 +-------------+-----------------+---------------+ 237 | Cell | CREATE/READ/ | 6t/Cell | 238 | List | DELETE/UPDATE | | 239 +-------------+-----------------+---------------+ 240 | Time | CREATE/READ/ | 6t/TimeSource | 241 | Source | DELETE/UPDATE | | 242 +-------------+-----------------+---------------+ 243 | LabelSwitch | CREATE/READ/ | 6t/LblSwitch | 244 | List | DELETE/UPDATE | | 245 +-------------+-----------------+---------------+ 246 | Track | CREATE/READ/ | 6t/Track | 247 | List | DELETE/UPDATE | | 248 +-------------+-----------------+---------------+ 249 | EB | CREATE/READ/ | 6t/EB | 250 | List | DELETE/UPDATE | | 251 +-------------+-----------------+---------------+ 252 | Chunk | CREATE/READ/ | 6t/Chunk | 253 | List | DELETE/UPDATE | | 254 +-------------+-----------------+---------------+ 256 Figure 3: List of Management Resources 258 In the following table, we provide an example about how Neighbor List 259 components (leafs in the YANG model) can be addressed. 261 +-------------+---------------------------+ 262 | Field name | URI path | 263 +-------------+---------------------------+ 264 | Neighbor | 6t/Neighbor/TargetNodeAddr| 265 | Addr | | 266 +-------------+---------------------------+ 267 | ASN | 6t/Neighbor/ASN | 268 +-------------+---------------------------+ 269 | RSSI | 6t/Neighbor/RSSI | 270 +-------------+---------------------------+ 271 | LinkQuality | 6t/Neighbor/LinkQuality | 272 +-------------+---------------------------+ 274 Figure 4: Neighbor Table 276 4.3.2. Informational Resources 278 All the attributes in the Informational resources have the Read 279 accessibility. The following table lists the 6top informational 280 resources and the related URI paths. 282 +-------------+-----------------+-----------------------+ 283 | Name | Accessibility | URI path | 284 | | 6top Commands | | 285 +-------------+-----------------+-----------------------+ 286 | Queue | READ/CONFIGURE | 6t/Queue | 287 +-------------+-----------------+-----------------------+ 288 | Monitoring | READ/CONFIGURE | 6t/MonitoringStatus | 289 | status | | | 290 +-------------+-----------------+-----------------------+ 291 | Statistics | READ/CONFIGURE | 6t/StatisticsMetrics | 292 | metrics | | | 293 +-------------+-----------------+-----------------------+ 295 Figure 5: List of Informational Resources 297 4.3.3. Message Formats 299 GET messages do not contain any payload. However, they can contain a 300 query option to filter on the resource that is being retrieved. An 301 example query on the neighbor list is: 303 +------------------------------------------+ 304 Header | GET | 305 +------------------------------------------+ 306 Uri-Path| /6t/Neighbor | 307 +------------------------------------------+ 308 Options | Accept: application/cbor | 309 | Uri-Query: ABNF(TargetNodeAddr==0x1234) | 310 +------------------------------------------+ 312 Figure 6: Example GET message 314 Since this resources points to the entire neighbor list, the response 315 returns all the entries (the list of neighbors of that node) and all 316 fields in each entry (i.e. entry for a neighbor) of the list in CBOR 317 format. A request with a Uri-Query option may be used to retrieve 318 only specific entries in the list. The value of Uri-Query MUST be in 319 the ABNF format as described in [RFC5234]. 321 Resources that point to collection within a list, such as '/6t/ 322 Neighbor/TargetNodeAddr', returns only the values in the 323 TargetNodeAddr column of the Neighbor list. The usage of the Uri- 324 Query option has the same effect of filtering on the result. 326 The endpoint MUST appropriately respond with a 2.05 Content or 4.04 327 Not Found message as defined in [I-D.ietf-core-coap]. If the 328 resource is found then the payload of the response MUST contain a 329 CBOR representation of the data that is referenced by the URI. 331 To create or update a Neighbor, the CoAP client MUST send a POST 332 message as shown in Figure 7. The payload MUST describe the argument 333 that is passed to 6top in CBOR format. 335 +-------------------------------------+ 336 Header | POST | 337 +-------------------------------------+ 338 Uri-Path| /6t/Neighbor | 339 +-------------------------------------+ 340 Payload | CBOR( {TargetNodeAddr: 0x1234} ) | 341 +-------------------------------------+ 343 Figure 7: Example POST message 345 The POST method may not be used on resources that are collection 346 within a list, such as '/6t/Neighbor/TargetNodeAddr'. 348 To delete a Neighbor, the CoAP client MUST send a DELETE message as 349 shown in Figure 8. 351 +-------------------------------------+ 352 Header | DELETE | 353 +-------------------------------------+ 354 Uri-Path| /6t/Neighbor | 355 +-------------------------------------+ 356 Options | Uri-Query: ABNF(TargetNodeAddr | 357 | == 0x1234) | 358 +-------------------------------------+ 360 Figure 8: Example DELETE message 362 A DELETE message SHOULD always contain a Uri-Query option in order to 363 clearly specify which entry(s) within the list must be deleted. 364 Ideally, the CoAP client SHOULD make one call per entry that must be 365 deleted. An implementation may decide whether or not a DELETE method 366 on '/6t/Neighbor' may be allowed. 368 The endpoint MUST appropriately respond with a 2.02 (Deleted) 369 message. 371 A sample of mapping between CoAP methods and 6top commands for 372 manipulating the neighbor list is shown in the figure below. 374 +--------------------+----------------+---------------+-------------+ 375 | CoAP method | 6top command |6top behaviour |CoAP Response| 376 +--------------------+----------------+---------------+-------------+ 377 | POST /6t/Neighbor | Create.neighbor| Adds a | 2.01 Created| 378 | CBOR( | | neighbor | | 379 | {TargetNodeAddr: | (address,stats)| | | 380 | 1234}) | | | | 381 +--------------------+----------------+---------------+-------------+ 382 | GET /6t/Neighbor | Read.all. | Reads | 2.05 Content| 383 | | neighbor() | all | CBOR(Neigh- | 384 | | | neighbors | bor List) | 385 +--------------------+----------------+---------------+-------------+ 386 | GET /6t/Neighbor | Read.neighbor | Reads neighbor| 2.05 Content| 387 | Uri-Query - | (address) | information | CBOR(Neigh- | 388 | TargetNodeAddr: | | | bor List) | 389 | 1234}) | | | | 390 +--------------------+----------------+---------------+-------------+ 391 | POST /6t/Neighbor | Update.neighbor| Updates an | 2.04 Changed| 392 | CBOR( | (address,stats)| entry | | 393 | {TargetNodeAddr: | | | | 394 | 1234}) | | | | 395 +--------------------+----------------+---------------+-------------+ 396 | DELETE /6t/Neighbor|Delete.neighbor | Removes | 2.02 Deleted| 397 | Uri-Query - | (address) | the neighbor | | 398 | TargetNodeAddr | | | | 399 | == 1234}) | | | | 400 +--------------------+----------------+---------------+-------------+ 402 Figure 9: CoAP methods and resulting invocation 6top commands 404 4.3.4. Extensible Resources 406 Extensible resources are to be used when a higher layer entity wants 407 to be notified of an event. An event may be defined as the result of 408 a mathematical operation on a 6top resource. For example, the CoAP 409 client might want to monitor when the DAG rank of a particular node 410 crosses a threshold. Once the extensible resource is installed the 411 CoAP client uses the observe mechanism defined in 412 [I-D.ietf-core-observe] to monitor the resource. 414 4.3.4.1. Defining new resources 416 An extensible resource path MUST always start with '/6t/custom' and 417 follow the guideline for URI naming as described in 4.1. The event 418 associated with the extensible resource must be defined using the 419 ABNF notation described in [RFC5234]. 421 An extensible resource may be created by performing POST operation to 422 the resource '/6t/custom' with the following payload encoded using 423 CBOR. 425 +---------------+------------+ 426 | Field Name | Type | 427 +---------------+------------+ 428 | Resource | String | 429 | Name | | 430 +---------------+------------+ 431 | Event | String | 432 | Definition | | 433 +---------------+------------+ 435 Figure 10: Payload format for creating an Extensible Resource 437 4.4. Example 439 This section gives a number of short examples of how to use the data 440 model and CoAP mapping defined in this document. 442 4.4.1. Request-Response 444 Figure 11 shows how a CoAP client adds an entry in the neighbor list 445 of node A. This new neighbor has a target node address 0x1234. The 446 client sends out a POST request containing the CBOR encoding of 447 '{TargetNodeAddr: 1234}'. This message is received and processed by 448 the CoAP endpoint of Node A and in turn, the 6top command, 449 Create.neighbor is invoked with the appropriate parameters. In this 450 case, the address is the 'TargetNodeAddr' parameter passed in the 451 payload of the POST message and the stats argument has the default 452 value. In the response to the invocation of the Create.neighbor 453 command, the 6top sublayer adds an entry to the neighbor list with 454 appropriate values and returns a confirm message. The CoAP endpoint 455 in turn send out an appropriate CoAP response to indicate success. 456 If the addition of the neighbor failed, a failure message will be 457 returned. 459 CoAP Client Node A Node A 460 (CoAP-endpoint) (6top sublayer) 461 | CoAP Request | | 462 |- - - - - - - - - - - ->| 6top Request | 463 | POST /6t/Neighbor |----------------------->| 464 | payload: | Create.neighbor | Adds a 465 | CBOR({TargertNodeAddr: | (address,stats) | neighbor 466 | 1234}) | | with address 467 | | | 1234 468 | | 6top Confirm | 469 | CoAP Response |<-----------------------| 470 |<- - - - - - - - - - - -| | 471 | | | 472 | | | 474 Figure 11: Example of adding a neighbor 476 In Figure 12, a CoAP client reads a neighbor entry from node A. This 477 neighbor has a target node address 0x1234. 479 CoAP Client Node A Node A 480 (CoAP-endpoint) (6top sublayer) 481 | CoAP Request | | 482 |- - - - - - - - - - - ->| 6top Request | 483 | GET /6t/Neighbor |----------------------->| 484 | Uri-Query - | Read.neighbor(address) |Reads neighbor 485 | TargetNodeAddr | |information 486 | == 0x1234 | | 487 | | | 488 | | 6top Confirm | 489 | CoAP Response |<-----------------------| 490 |<- - - - - - - - - - - -| Reads neighbor | 491 | 2.05 Content | information | 492 | | | 494 Figure 12: Example of reading a neighbor 496 4.4.2. Publish-Subscribe 498 In Figure 13, a CoAP client subscribes to Monitoring Status of node 499 A. The Monitoring status of Node A is constantly monitored by the 500 CoAP client. 502 CoAP Client Node A Node A 503 (CoAP-endpoint) (6top sublayer) 504 | CoAP Register | | 505 |- - - - - - - - - - - - >| 6top Request | 506 | GET /6t/MonitoringStatus|----------------------->| 507 | | Read.Monitoring.Status |Reads 508 | | |the current 509 | | |Monitoring 510 | | |status 511 | | 6top Notification | 512 | CoAP Notification |<-----------------------| 513 |<- - - - - - - - - - - - | Reads the current | 514 | 2.05 Content | Monitoring status | 515 | | |The Status 516 | | |changes 517 | | 6top Notification | 518 | CoAP Notification |<-----------------------| 519 |<- - - - - - - - - - - - | Notifies upon the | 520 | 2.05 Content | status change | 521 | | |The Status 522 | | |changes 523 | | 6top Notification | 524 | CoAP Notification |<-----------------------| 525 |<- - - - - - - - - - - - | Notifies upon the | 526 | 2.05 Content | status change | 527 | | | 529 Figure 13: Example of Subscribing to Monitoring Status 531 5. References 533 5.1. Normative References 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", BCP 14, RFC 2119, March 1997. 538 5.2. Informative References 540 [I-D.bormann-cbor] 541 Bormann, C. and P. Hoffman, "Concise Binary Object 542 Representation (CBOR)", draft-bormann-cbor-09 (work in 543 progress), September 2013. 545 [I-D.ietf-core-coap] 546 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 547 Application Protocol (CoAP)", draft-ietf-core-coap-18 548 (work in progress), June 2013. 550 [I-D.ietf-core-observe] 551 Hartke, K., "Observing Resources in CoAP", draft-ietf- 552 core-observe-11 (work in progress), October 2013. 554 [I-D.wang-6tisch-6top-interface] 555 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 556 Operation Sublayer (6top) Interface", draft-wang-6tisch- 557 6top-interface-02 (work in progress), February 2014. 559 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 560 Resource Identifier (URI): Generic Syntax", STD 66, RFC 561 3986, January 2005. 563 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 564 Specifications: ABNF", STD 68, RFC 5234, January 2008. 566 5.3. External Informative References 568 [IEEE802154e] 569 IEEE standard for Information Technology, "IEEE std. 570 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 571 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 572 2012. 574 Appendix A. 576 Guidelines for constructing URI path names: 578 1. The first letter of each element of the path SHOULD be 579 capitalized 581 2. If an element has multiple words, each the first letter of each 582 work SHOULD be capitalized 584 Authors' Addresses 586 Raghuram S Sudhaakar (editor) 587 Cisco Systems, Inc 588 Building 24 589 510 McCarthy Blvd 590 San Jose 95135 591 USA 593 Phone: +1 408 853 0844 594 Email: rsudhaak@cisco.com 595 Pouria Zand 596 University of Twente 597 Department of Computer Science 598 Zilverling Building 599 Enschede 7522 NB 600 The Netherlands 602 Phone: +31 619040718 603 Email: p.zand@utwente.nl