idnits 2.17.1 draft-rahman-core-sleepy-05.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 (February 12, 2014) is 3719 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE WG A. Rahman 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Standards Track February 12, 2014 5 Expires: August 16, 2014 7 Enhanced Sleepy Node Support for CoAP 8 draft-rahman-core-sleepy-05 10 Abstract 12 CoAP is a specialized web transfer protocol for constrained devices. 13 These devices typically have some combination of limited battery 14 power, small memory footprint and low throughput links. It is 15 expected that in CoAP networks there will be a certain portion of 16 devices that are "sleepy" and which may occasionally go into a sleep 17 mode (i.e. go into a low power state to conserve power) and 18 temporarily suspend CoAP protocol communication. This document 19 proposes a minimal and efficient mechanism building on the Resource 20 Directory (RD) functionality to enhance sleepy node support in CoAP 21 networks. The RD functionality may be incorporated as part of a CoAP 22 Proxy. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 16, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. RD Based Sleep Tracking . . . . . . . . . . . . . . . . . 4 62 3.2. Example of Synchronous RD Based Sleep Tracking . . . . . 5 63 3.3. Example of Asynchronous RD Based Sleep Tracking . . . . . 7 64 3.4. RD Caching Proxy . . . . . . . . . . . . . . . . . . . . 11 65 4. Performance Results . . . . . . . . . . . . . . . . . . . . . 11 66 4.1. Prototype Setup . . . . . . . . . . . . . . . . . . . . . 11 67 4.2. Initial Results . . . . . . . . . . . . . . . . . . . . . 13 68 4.3. Comparison with Observe . . . . . . . . . . . . . . . . . 13 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 8.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Terminology and Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 This document assumes readers are familiar with the terms and 84 concepts that are used in [I-D.ietf-core-coap] and [RFC6690]. In 85 addition, this document defines the following terminology: 87 Sleepy Node 88 A sleepy node is a CoAP client or server that may sometimes go 89 into a sleep mode (i.e. go into a low power state to conserve 90 power) and temporarily suspend CoAP protocol communication. A 91 sleepy node will otherwise remain in a fully powered on state 92 where it has the capability to perform full CoAP protocol 93 communication. 95 Non-Sleepy Node 96 A non-sleepy node is a CoAP client or server that always remains 97 in a fully powered on state (i.e. always awake) where it has the 98 capability to perform full CoAP protocol communication. The 99 general operation of non-sleepy nodes is assumed to be well known 100 and so are not explicitly spelled out in this document except 101 where needed for clarity. 103 2. Introduction 105 The current CoAP approach provides a minimal support of sleepy nodes 106 as follows: 108 o [I-D.ietf-core-coap] defines CoAP proxies which can cache and 109 service requests for sleepy CoAP servers. A client explicitly 110 sends a CoAP request (GET) to a forward proxy (identified by its 111 IP address) while indicating the URI (of the resource of interest) 112 associated to a sleepy CoAP origin server. If the proxy has a 113 valid representation of the resource in its cache it can then 114 respond directly to the client regardless of the current sleep 115 state of the origin server. Otherwise the proxy has to attempt to 116 retrieve (GET) the resource from the sleepy origin server. The 117 attempt may or may not be successful depending on the sleep state 118 of the origin server. 120 o [RFC6690] and [I-D.ietf-core-resource-directory] defines a 121 Resource Directory (RD) mechanism where sleepy CoAP servers can 122 register/update (POST/PUT to "/.well-known/core") their list of 123 resources on a central (non-sleepy) RD server. This allows 124 clients to discover the list of resources from the RD (GET /rd- 125 lookup/...) for a sleepy server, regardless of its current sleep 126 state. Unlike a proxy, the RD stores only the URIs for other 127 nodes, and not the actual resource representation [RFC6690] . The 128 client then may attempt to operate on (GET/PUT/POST/DELETE) the 129 desired resource at the sleepy origin server. This attempt may or 130 may not be successful depending on the sleep state of the origin 131 server. 133 o Lower layer (i.e. below the IP layer) support for sleepy nodes 134 exist in most wireless technologies (e.g. IEEE 802.11 (WiFi), and 135 IEEE 802.15.4 (ZigBee)). For example, most wireless technologies 136 support limited functionality such as packet scheduling to account 137 for sleepy nodes in their physical and MAC layer protocols. This 138 lower layer functionality is not aware of any specific timing or 139 operational aspects of application layer protocols like CoAP. 141 Some more background information regarding Sleepy Nodes can be found 142 in [I-D.rahman-core-sleepy-nodes-do-we-need]. 144 3. Proposal 146 3.1. RD Based Sleep Tracking 148 The current CoAP approach to support sleepy nodes can be 149 significantly improved by introducing RD based mechanisms for a CoAP 150 client to determine whether: 152 o A targeted resource is located on a sleepy server. 154 o A sleepy server is currently in sleep mode or not. 156 We define the following new parameters to characterize a sleepy node: 158 o SleepState - Indicates whether the node is currently in sleep mode 159 or not (i.e. Sleeping or Awake). 161 o SleepDuration - Indicates the maximum duration of time that the 162 node stays in sleep mode. 164 o TimeSleeping - Indicates the length of time the node has been 165 sleeping (i.e. if Sleep State = Sleeping). 167 o NextSleep - Indicates the next time the node will go to sleep 168 (i.e. if Sleep State = Awake). 170 These parameters are all server (node) level and are new parameters 171 added to the RD URI Template Variables defined in 172 [I-D.ietf-core-resource-directory]. 174 We also define a new lookup-type ("ss") for the RD lookup interface 175 specified in [I-D.ietf-core-resource-directory]. This new lookup- 176 type supports looking up the SleepState of a specified end-point. 178 The three time based parameters (SleepDuration, TimeSleeping, 179 NextSleep) can be based on either an absolute network time (for a 180 time synchronized network) or a relative local time (measured at the 181 local node). 183 Following the approach of [RFC6690] and 184 [I-D.ietf-core-resource-directory], sleep parameters for sleepy 185 servers can be stored by the server in the RD and accessed by all 186 interested clients. Examples of using these parameters in a 187 synchronous or asynchronous manner are shown in the following 188 sections. 190 3.2. Example of Synchronous RD Based Sleep Tracking 192 Figure 1 shows an example of using RD based sleep tracking in a 193 synchronous fashion: 195 (1) SleepyNode-1 is awake and having previously discovered the local 196 RD, stores its CORE link format in the RD (POST/rd) identified by its 197 entry point (?ep=SleepyNode-1). The sleep parameters are also 198 updated as part of this step. 200 (2)-(3) RD services the POST and stores the CORE link format and 201 starts the sleep timers for this node. 203 (4) SleepyNode-1 falls asleep. 205 (5) A client is interested in temperature sensors in this domain and 206 does a lookup on the RD. 208 (6) The RD does a lookup and finds that SleepyNode-1 is the only node 209 meeting the match and sends back the required info including the 210 Sleep parameters. 212 (7) From the sleep parameters, the client knows that the node is 213 currently asleep and so internally schedules to send the GET request 214 when the node wakes up (plus a small safety hysteresis). 216 (8)-(9) Client sends GET request for temperature sensors and 217 successfully receives the content as SleepyNode-1 is awake. 219 SleepyNode-1 Resource 220 Server Directory Client 221 | | | 222 +----------+ | | 223 | Time = 0 | | | 224 +----------+ | | 225 | | | 226 |(1) CoAP POST | | 227 | /rd, | | 228 | ?ep="SleepyNode-1"; | | 229 | ?SleepDuration="30-Minutes"; | | 230 | ?SleepState="Awake"; | | 231 | ?NextSleep="5-Minutes"; | | 232 | PAYLOAD: | | 233 | "" | | 234 |---------------------------------- >| | 235 | | | 236 | (2) RD services the | | 237 | Registration | | 238 | Request and | | 239 | starts Sleep | | 240 | timers | | 241 | | | 242 |(3) 2.01 Created | | 243 | Location: /rd/4321 | | 244 |<-----------------------------------| | 245 | | | 246 +-------------------+ | | 247 | Time = 5 minutes | | | 248 +-------------------+ | | 249 | | | 250 |(4) SleepyNode-1 falls asleep | | 251 | | | 252 +-------------------+ | | 253 | Time = 15 minutes | | | 254 +-------------------+ | | 255 | | | 256 | | 257 | (5) CoAP GET | 258 | /rd-lookup/res?rt=Temperature | 259 | |<-------------------------| 260 | | | 261 | | | 262 | | 263 | (6) 2.05 Content | 264 | ; | 265 | SleepDuration="30-Minutes"; | 266 | SleepState="Sleeping"; | 267 | TimeSleeping="10-Minutes"; | 268 | PAYLOAD: | 269 | rt="Temperature" | 270 | |------------------------->| 271 | | | 272 | | | 273 | | | 274 | | | 275 | | 276 | (7) Since node is asleep Client | 277 | waits 20 minutes until it awakes | 278 | | | 279 | | | 280 +-------------------+ | | 281 | Time = 31 minutes | | | 282 +-------------------+ | | 283 | | | 284 | | 285 | (8)CoAP GET | 286 | | 287 |<--------------------------------------------------------------| 288 | | 289 |-------------------------------------------------------------->| 290 | (9) 2.05 Content | 291 | | | 292 | | | 294 Figure 1: Synchronous Resource Directory Based Sleep Tracking 296 3.3. Example of Asynchronous RD Based Sleep Tracking 298 Figure 2 shows an example of using RD based sleep tracking in an 299 asynchronous fashion: 301 (1) SleepyNode-1 is awake and having previously discovered the local 302 RD, stores its CORE link format in the RD (POST/rd) identified by its 303 entry point (?ep=SleepyNode-1). 305 (2)-(3) RD services the POST and stores the CORE link format. 307 (4) A client is interested in temperature sensors in this domain and 308 does a lookup on the RD for all sensors that are currently awake. 310 (5) The RD does a lookup and finds that SleepyNode-1 is the only node 311 meeting the match and sends back the required info. 313 (6)-(7) Using the sleep state lookup functionality (lookup-type := 314 "ss"), the client adds itself to the list of observers to get 315 SleepState updates from RD for SleepyNode-1 [I-D.ietf-core-observe]. 317 (8)-(9) Client performs RD 'resource' lookup to find URI of 318 temperature sensor of resource hosted on SleepyNode-1. 320 (10)-(13) SleepyNode-1 prepares to goes to sleep and updates the 321 SleepState in the RD. 323 (14) RD notifies the client through previously established observe 324 relationship. 326 (15) Client application wants to get the temperature now but does not 327 send the request as it knows SleepyNode-1 is currently sleeping. 329 (16)-(19) SleepyNode-1 wakes up and updates the SleepState in the RD. 331 (20)-(21) RD notifies the client through previously established 332 observe relationship. 334 (22)-(23) Client sends GET request for temperature sensors and 335 successfully receives the content as SleepyNode-1 is awake. 337 SleepyNode-1 Resource 338 Server Directory Client 339 | | | 340 | | | 341 |(1) CoAP POST | | 342 | /rd, | | 343 | ?ep=SleepyNode-1; | | 344 | ?SleepState=Awake; | | 345 | PAYLOAD: | | 346 | "" | | 347 |---------------------------------- >| | 348 | | | 349 | (2) RD services the | | 350 | Registration | | 351 | Request | | 352 | | | 353 |(3) 2.01 Created | | 354 | Location: /rd/4321 | | 355 |<-----------------------------------| | 356 | | | 357 | | | 358 | (4) Client performs RD | 359 | end-point lookup to | 360 | find endpoint that | 361 | has temperature | 362 | sensor and is awake | 363 | | 364 | CoAP GET | 365 | /rd-lookup/ep?rt=Temperature&SleepState=Awake| 366 | |<-------------------------| 367 | | | 368 | | | 369 | (5) 2.05 Content | 370 | ;ep="SleepyNode-1" | 371 | |------------------------->| 372 | | | 373 | | | 374 | (6) Client adds itself | 375 | to list of observers| 376 | to get SleepState | 377 | updates from RD for | 378 | SleepyNode-1 | 379 | | 380 | | 381 | CoAP GET | 382 | /rd-lookup/ss?ep=SleepyNode-1 | 383 | Observe: 0 | 384 | Token: 0x4a | 385 | |<-------------------------| 386 | | | 387 | | | 388 | (7) 2.05 Content | 389 | Observe: 1 | 390 | Token: 0x4a | 391 | SleepState="Awake" | 392 | |------------------------->| 393 | | | 394 | | | 395 | (8) Client performs RD | 396 | 'resource' lookup | 397 | to find URI of | 398 | temperature sensor | 399 | of resource hosted | 400 | on SleepyNode-1 | 401 | | 402 | CoAP GET | 403 | /rd-lookup/res?rt=Temperature&ep="SleepyNode-1"| 404 | |<-------------------------| 405 | | | 406 | | | 407 | (9) 2.05 Content | 408 | ; | 409 | |------------------------->| 410 | | | 411 | | | 412 ... .... 413 |(10) SleepyNode-1 prepares to go | | 414 | to sleep so it updates | | 415 | SleepState | | 416 | | | 417 | CoAP PUT | | 418 | /rd/4321, | | 419 | ?SleepState=Sleeping | | 420 |---------------------------------- >| | 421 | | | 422 | (11) RD updates | | 423 | SleepState of | | 424 | SleepyNode-1 | | 425 | | | 426 |(12) 2.04 Changed | | 427 |<-----------------------------------| | 428 | | | 429 |(13) SleepyNode-1 goes to sleep | | 430 | | | 431 | | | 432 | (14) RD sends notification to client | 433 | 2.05 Content | 434 | Observe: 2 | 435 | Token: 0x4a | 436 | SleepState="Sleeping" | 437 | |------------------------->| 438 ... .... 439 | | | 440 | | (15) Client has GET | 441 | | request for | 442 | | SleepyNode-1 but | 443 | | cannot send it since| 444 | | SleepyNode-1 is not | 445 | | awake | 446 |(16) SleepyNode-1 wakes up | | 447 | | | 448 | | | 449 |(17) SleepyNode-1 updates | | 450 | SleepState | | 451 | | | 452 | CoAP PUT | | 453 | /rd/4321, | | 454 | ?SleepState=Awake; | | 455 |---------------------------------- >| | 456 | | | 457 | | | 458 | (18) RD updates | | 459 | sleep state | | 460 | | | 461 |(19) 2.04 Changed | | 462 |<-----------------------------------| | 463 | | | 464 | (20) 2.05 Content | 465 | Observe: 3 | 466 | Token: 0x4a | 467 | ; | 468 | SleepState="Awake" | 469 | |------------------------->| 470 | | | 471 | | | 472 | | (21) Client detects | 473 | | SleepyNode-1 is | 474 | | awake | 475 | | | 476 | (22) CoAP GET | 477 | | 478 |<--------------------------------------------------------------| 479 | | 480 |-------------------------------------------------------------->| 481 | (23) 2.05 Content | 482 | | 484 Figure 2: Asynchronous Resource Directory Based Sleep Tracking 486 3.4. RD Caching Proxy 488 It would be useful for an RD to be able to indicate which proxy 489 performs caching for Sleepy CoAP nodes (see Section 2). This would 490 be done through a new RD "CachingProxy" attribute for each device 491 (similiar to the attributes defined in Section 3.1): 493 o An RD may be co-located with a proxy that performs caching for 494 CoAP nodes. In this case, the RD automatically adds itself to 495 each CachingProxy entry. 497 o The sleepy node itself could suggest the CachingProxy if it is 498 peered to a specific proxy. 500 This parameter would be added to the RD URI Template Variables 501 defined in [I-D.ietf-core-resource-directory]. 503 4. Performance Results 505 4.1. Prototype Setup 507 A simple prototype was implemented to validate certain aspects of the 508 performance of the proposed CoAP sleepy node support protocol 509 enhancement. The network for the prototype is shown in Figure 3. 511 Key aspects of the prototype are as follows: 513 o There are two modes of operation: "Caching Only" and "Caching and 514 Sleep Aware" 516 o In "Caching Only" mode the Reverse Proxy will cache responses and 517 service new requests according to the "Max-Age" parameter as 518 defined in [I-D.ietf-core-coap]. 520 o In "Caching and Sleep Aware" mode the Reverse Proxy will also 521 cache responses and service new requests according to "Max-Age". 522 However, if the cache is empty (e.g. exceeded Max-Age) then there 523 will be extra sleep aware functionality. Specifically, the proxy 524 will also be aware of the "SleepDuration", "NextSleep" and 525 "SleepState" sleepy node parameters as defined in Section 3.1. 526 Based on these sleep parameters: 528 * For servers that are asleep but expected to wake up soon: The 529 proxy will immediately send a non-piggy backed ACK to the 530 client. Then store-and-forward the request to the server when 531 it wakes up, and then return the non-piggybacked response to 532 the client thereafter. 534 * For servers that are asleep but not expected to wake up soon: 535 The proxy will immediately send a "5.03 Service Unavailable 536 (and retry after)" to the client. 538 o The key variables in the experiment are: (1) Number of clients; 539 (2) Number of sleepy servers; (3) Delay between client requests; 540 (4) MaxAge; (5) SleepDuration; (6) NextSleep; and (7) SleepState. 542 o The target of the experiment will be to measure the amount of 543 traffic over the network in the two modes of operation (for the 544 same input client requests profile). It is hypothesized that the 545 "Caching and Sleep Aware" mode will have the minimal amount of 546 network traffic indicating that the Sleep Aware network will be 547 the most efficient. 549 Constrained Network 550 -------------------- 551 / \ 552 --- +----------+ /-----\ \ 553 / \ | CoAP | CoAP \ 554 | | | Reverse | server \ 555 CoAP | | | Proxy | \-----/ || 556 +------+ Request | | | | || 557 |CoAP |-------------| |---->| +-----+ | Req /-----\ || 558 |Client| | | | |Cache| |------->| CoAP || 559 | |<------------| |-----| +-----+ |<-------|server || 560 +------+ CoAP | | | | Resp \-----/ || 561 Response | Corp| |------ | || 562 | LAN | |RD | | || 563 | | |Sleep| | || 564 \ / |Param| | / 565 --- | | | / 566 +----------+ /-----\ / 567 \ CoAP / 568 \ server / 569 \ \-----/ / 570 ---------------- 572 Figure 3: Prototype Configuration 574 4.2. Initial Results 576 Baseline performance results of A CoAP system with Sleep Aware Proxy 577 support described in Section 4.1 is given in [IETF86Results] (see pg. 578 65-95). Key conclusions were: 580 o If only GETs are considered, a cache based system is efficient as 581 long as the cache is valid (i.e before Max-Age). 583 o However, since the cache often expires, a Sleep Aware Proxy 584 further minimizes the number of GET transactions. Also, the Sleep 585 Aware Proxy reduces number of transactions for other methods (e.g. 586 PUTs) where a cache does not help. 588 4.3. Comparison with Observe 590 A comparison of the performance of a CoAP system with Sleep Aware 591 Proxy versus a CoAP system supporting Observe is given in 592 [IETF87Results] (see pg. 150-182). Key conclusions were: 594 o If only GETs are considered, an Observe based system is quite 595 efficient. 597 o However, Observe in combination with Sleep Aware Proxy further 598 minimizes the number of GET transactions. Also, the Sleep Aware 599 Proxy reduces number of transactions for other methods (e.g. PUTs) 600 where Observe does not help. 602 5. Acknowledgements 604 Thanks to Carsten Bormann, Esko Dijk, Thomas Fossati, Salvatore 605 Loreto, Dale Seed, and Zach Shelby for valuable discussions and 606 feedback on this document. 608 6. IANA Considerations 610 This memo includes no request to IANA. 612 7. Security Considerations 614 TBD. (All drafts are required to have a security considerations 615 section. See RFC 3552 [RFC3552] for a guide.) 617 8. References 619 8.1. Normative References 621 [I-D.ietf-core-coap] 622 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 623 Application Protocol (CoAP)", draft-ietf-core-coap-18 624 (work in progress), June 2013. 626 [I-D.ietf-core-observe] 627 Hartke, K., "Observing Resources in CoAP", draft-ietf- 628 core-observe-11 (work in progress), October 2013. 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, March 1997. 633 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 634 Format", RFC 6690, August 2012. 636 8.2. Informative References 638 [I-D.ietf-core-resource-directory] 639 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 640 Directory", draft-ietf-core-resource-directory-01 (work in 641 progress), December 2013. 643 [I-D.rahman-core-sleepy-nodes-do-we-need] 644 Rahman, A., "Sleepy Devices: Do we need to Support them in 645 CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work 646 in progress), February 2014. 648 [IETF86Results] 649 Rahman, A., "IETF-86 Sleepy Node Performance Results", 650 March 2013, . 653 [IETF87Results] 654 Rahman, A., "IETF-87 Sleepy Node Performance Results", 655 July 2013, . 658 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 659 Text on Security Considerations", BCP 72, RFC 3552, July 660 2003. 662 Author's Address 664 Akbar Rahman 665 InterDigital Communications, LLC 666 Montreal, Quebec H3A 3G4 667 Canada 669 Phone: +1-514-585-0761 670 Email: akbar.rahman@interdigital.com