idnits 2.17.1 draft-ietf-roll-home-routing-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group A. Brandt 2 Internet Draft Zensys, Inc. 3 Intended status: Informational G. Porcu 4 Expires: January 2009 Telecom Italia 5 July 14, 2008 7 Home Automation Routing Requirement in Low Power and Lossy Networks 8 draft-ietf-roll-home-routing-reqs-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 14, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document presents home control and automation application 42 specific requirements for ROuting in Low power and Lossy networks 43 (ROLL). In a modern home, a high number of wireless devices are used 44 for a wide set of purposes. Examples include lighting control, 45 heating control, sensors, leak detectors, healthcare systems and 46 advanced remote controls. Because such devices only cover a limited 47 radio range, multi-hop routing is often required. The aim of this 48 document is to specify the routing requirements for networks 49 comprising such constrained devices in a home network environment. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [RFC2119]. 57 Table of Contents 59 1. Terminology....................................................3 60 2. Introduction...................................................3 61 3. Home automation applications...................................4 62 3.1. Turning off the house when leaving........................4 63 3.2. Energy conservation and optimizing energy consumption.....5 64 3.3. Moving a remote control around............................5 65 3.4. Adding a new lamp module to the system....................6 66 3.5. Controlling battery operated window shades................6 67 3.6. Remote video surveillance.................................6 68 3.7. Healthcare................................................7 69 3.7.1. At-home health reporting.............................7 70 3.7.2. At-home health monitoring............................8 71 3.7.3. Healthcare routing considerations....................8 72 3.8. Alarm systems.............................................8 73 3.9. Battery-powered devices...................................9 74 4. Unique requirements of home automation applications............9 75 4.1. Support of groupcast......................................9 76 4.2. Constraint-based Routing.................................10 77 4.3. Support of Mobility......................................10 78 4.4. Support of Periodical Scanning...........................11 79 4.5. Scalability..............................................11 80 4.6. Convergence Time.........................................11 81 4.7. Manageability............................................12 82 5. Traffic Pattern...............................................12 83 6. Open issues...................................................13 84 7. Security Considerations.......................................13 85 8. IANA Considerations...........................................13 86 9. Acknowledgments...............................................13 87 10. References...................................................14 88 10.1. Normative References....................................14 89 10.2. Informative References..................................14 90 Disclaimer of Validity...........................................15 92 1. Terminology 94 ROLL: ROuting in Low-power and Lossy networks 96 ROLL device: A ROLL network node with constrained CPU and memory 97 resources; potentially constrained power resources. 99 Access Point: The access point is an infrastructure device that 100 connects the low power and lossy network system to the 101 Internet, possibly via a customer premises local area 102 network (LAN). 104 LAN: Local Area Network. 106 PAN: Personal Area Network. 107 A geographically limited wireless network based on 108 e.g. 802.15.4 or Z-Wave radio. 110 Channel: Radio frequency band used to transmit a modulated 111 signal carrying packets. 113 Downstream: Data direction traveling from a Local Area Network 114 (LAN) to a Personal Area Network (PAN) device. 116 Upstream: Data direction traveling from a PAN to a LAN device. 118 Sensor: A PAN device that measures data and/or detects an 119 event. 121 2. Introduction 123 This document presents the home control and automation application 124 specific requirements for Routing in Low power and Lossy Networks 125 (ROLL). In a modern home, a high number of wireless devices are used 126 for a wide set of purposes. Examples include lighting control 127 modules, heating control panels, light sensors, temperature sensors, 128 gas/water leak detectors, motion detectors, video surveillance, 129 healthcare systems and advanced remote controls. Basic home control 130 modules such as wall switches and plug-in modules may be turned into 131 an advanced home automation solution via the use of an IP-enabled 132 application responding to events generated by wall switches, motion 133 sensors, light sensors, rain sensors, and so on. 135 Because such devices only cover a limited radio range, multi-hop 136 routing is often required. These devices are usually highly 137 constrained in term of resources such as battery and memory and 138 operate in unstable environments. Persons moving around in a house, 139 opening or closing a door or starting a microwave oven affect the 140 reception of weak radio signals. Reflection and absorption may cause 141 a reliable radio link to turn unreliable for a period of time and 142 then being reusable again, thus the term "lossy". 144 Unlike other categories of PANs, the connected home area is very much 145 consumer-oriented. The implications on network nodes in this aspect, 146 is that devices are very cost sensitive, which leads to resource- 147 constrained environments having slow CPUs and small memory 148 footprints. At the same time, nodes have to be physically small which 149 puts a limit to the physical size of the battery; and thus, the 150 battery capacity. As a result, it is common for low-power sensor- 151 style nodes to shut down radio and CPU resources for most of the 152 time. Often, the radio uses the same power for listening as for 153 transmitting. 155 Section 3 describes a few typical use cases for home automation 156 applications. Section 4 discusses the routing requirements for 157 networks comprising such constrained devices in a home network 158 environment. These requirements may be overlapping requirements 159 derived from other application-specific requirements. 161 3. Home automation applications 163 Home automation applications represent a special segment of networked 164 wireless devices with its unique set of requirements. To facilitate 165 the requirements discussion in Section 4, this section lists a few 166 typical use cases of home automation applications. New applications 167 are being developed at a high pace and this section does not mean to 168 be exhaustive. Most home automation applications tend to be running 169 some kind of command/response protocol. The command may come from 170 several places. For instance a lamp may be turned on, not only be a 171 wall switch but also from a movement sensor. 173 3.1. Turning off the house when leaving 175 Using the direct analogy to an electronic car key, a house owner may 176 activate the "leaving home" function from an electronic house key, 177 mobile phone, etc. For the sake of visual impression, all lights 178 should turn off at the same time. At least, it should appear to 179 happen at the same time. A well-known problem in wireless home 180 automation is the "popcorn effect": Lamps are turned on one at a 181 time, at a rate so slow that it is clearly visible. Some existing 182 home automation solutions use a clever mix of a "subnet groupcast" 183 message with no acknowledgement and no forwarding before sending 184 acknowledged singlecast messages to each lighting device. 186 The controller forms the groups and decides which nodes should 187 receive "turn-off" or "turn-on" requests. 189 3.2. Energy conservation and optimizing energy consumption 191 Parts of the world using air conditioning may let shades go down and 192 turn off the AC device when leaving home. Air conditioning may start 193 by timer or via motion sensor when the owner returns home. The owner 194 may even activate the air conditioning via cell phone before getting 195 home. 197 Geographical areas using central heating may turn off heating when 198 not at home and use a reduced temperature during night time. 200 The power grid may experience periods where more wind-generated power 201 is produced than is needed. Typically this may happen during night 202 hours. The washing machine and dish washer may just as well work 203 while power is cheap. The electric car should also charge its 204 batteries on cheap power. 206 In periods where electricity demands exceed available supply, 207 appliances such as air conditioning, climate control systems, washing 208 machines etc. can be turned off to avoid overloading the power grid. 209 Wireless remote control of the household appliances is well-suited 210 for this application. The start/stop decision for the appliances can 211 be regulated by dynamic power pricing information obtained from the 212 electricity utility companies. Moreover, in order to achieve 213 effective electricity savings, the energy monitoring application 214 running on the Wireless Sensor Network (WSN) must guarantee that the 215 power consumption of the ROLL devices is much lower than that of the 216 appliance itself. 218 Most of these applications are mains powered and are thus ideal for 219 providing reliable, always-on routing resources. Battery-powered 220 nodes, by comparison, are constrained routing resources and may only 221 provide reliable routing under some circumstances. 223 3.3. Moving a remote control around 225 A remote control is a typical example of a mobile device in a home 226 automation network. An advanced remote control may be used for 227 dimming the light in the dining room while eating and later on, 228 turning up the music while doing the dishes in the kitchen. Reaction 229 must appear to be instant (within a few hundred milliseconds) even 230 when the remote control has moved to a new location. The remote 231 control may be communicating to either a central home automation 232 controller or directly to the lamps and the media center. 234 3.4. Adding a new lamp module to the system 236 Small-size, low-cost modules may have no user interface except for a 237 single button. Thus, an automated inclusion process is needed for 238 controllers to find new modules. Inclusion covers the detection of 239 neighbors and assignment of a unique node ID. Inclusion should be 240 completed within a few seconds. 242 Distribution of unique addresses is usually performed by a central 243 controller. In this case, it must be possible to route the inclusion 244 request from the joining node to the central controller even before 245 the joining node is assigned a unique address. 247 3.5. Controlling battery operated window shades 249 In consumer premises, window shades are often battery-powered as 250 there is no access to mains power over the windows. For battery 251 conservation purposes, the receiver is sleeping most of the time. A 252 home automation controller sending commands to window shades via ROLL 253 devices will have no problems delivering the packet to the router, 254 but the router may have to wait for some time before the command can 255 be delivered to the window shades if the receiver is sleeping; e.g. 256 up to 250ms. 258 3.6. Remote video surveillance 260 Remote video surveillance is a fairly classic application for Home 261 networking providing the ability for the end user to get a video 262 stream from a Web Cam reached via the Internet, which can be 263 triggered by the end-user that has received an alarm from a movement 264 sensor or smoke detector - or the user simply wants to check the home 265 status via video. 266 Note that in the former case, more than likely, there will be a form 267 of inter-device communication: indeed, upon detecting some movement 268 in the home, the movement sensor may send a request to the light 269 controller to turn-on the lights, to the Web Cam to start a video 270 stream that would then be directed to the end user (cell phone, PDA) 271 via the Internet. 272 By contrast with other applications, e.g. industrial sensors where 273 data would mainly be originated by sensor to a sink and vice versa, 274 this scenario implicates a direct inter-device communication between 275 ROLL devices. 277 3.7. Healthcare 279 By adding communication capability to devices, patients and elderly 280 citizens may be able to do simple measurements at home. Thanks to 281 online devices, a doctor can keep an eye on the patient's health and 282 receive warnings if a new trend is discovered by automated filters. 284 Fine-grained daily measurements presented in proper ways may allow 285 the doctor to establish a more precise diagnosis. 287 Such applications may be realized as wearable products which 288 frequently do a measurement and automatically deliver the result to a 289 data sink locally or over the Internet. 291 Applications falling in this category are referred to as at-home 292 health reporting. Whether measurements are done in a fixed interval 293 or if they are manually activated, they leave all processing to the 294 receiving data sink. 296 A more active category of applications may send an alarm if some 297 alarm condition is triggered. This category of applications is 298 referred to as at-home health monitoring. Measurements are 299 interpreted in the device and may cause reporting of an event if an 300 alarm is triggered. 302 Many implementations may overlap both categories. 304 3.7.1. At-home health reporting 306 Applications might include: 308 o Temperature 310 o Weight 312 o Blood pressure 314 o Insulin level 316 Measurements may be stored for long term statistics. At the same 317 time, a critically high blood pressure may cause the generation of an 318 alarm report. Refer to 3.7.2. 320 To avoid a high number of request messages, nodes may be configured 321 to autonomously do a measurement and send a report in intervals. 323 3.7.2. At-home health monitoring 325 An alarm event may become active e.g. if the measured blood pressure 326 exceeds a threshold or if a person falls to the ground. 328 Applications might include: 330 o Temperature 332 o Weight 334 o Blood pressure 336 o Insulin level 338 o Electrocardiogram (ECG) 340 o Position tracker 342 3.7.3. Healthcare routing considerations 344 From a ROLL perspective, all the above-mentioned applications may run 345 on battery. They may also be portable and therefore need to locate a 346 new neighbor router on a frequent basis. 347 Not being powered most of the time, the nodes should not be used as 348 routing nodes. However, sleeping, battery-powered nodes may be 349 involved in routing. Examples include cases where a person falls 350 during a power blackout. In that case it may be that no mains-powered 351 routers are available for forwarding the alarm message to a (battery- 352 backed) internet gateway located out of direct range. 354 Delivery of measurement data has a more relaxed requirement for route 355 discovery time compared to a remote control. On the other hand, it is 356 critical that a "person fell" alarm is actually delivered in the end. 358 3.8. Alarm systems 360 A home security alarm system is comprised of various devices like 361 vibration detectors, fire or carbon monoxide detection system, door 362 or window contacts, glass-break detector, presence sensor, panic 363 button, home security key. 365 Some smoke alarms are battery powered and at the same time mounted in 366 a high place. Battery-powered safety devices should only be used for 367 routing if no other alternatives exist to avoid draining the battery. 368 A smoke alarm with a drained battery does not provide a lot of 369 safety. Also, it may be inconvenient to exchange battery in a smoke 370 alarm. 372 Alarm system applications may have both a synchronous and an 373 asynchronous behavior; i.e. they may be periodically queried by a 374 central control application (e.g. for a periodical refreshment of the 375 network state), or send a message to the control application on their 376 own initiative basing upon the status of the environment they 377 monitor. 379 When a node (or a group of nodes) identifies a risk situation (e.g. 380 intrusion, smoke, fire), it sends an alarm message to the control 381 centre that could autonomously forward it via Internet or interact 382 with the WSN (e.g. trying to obtain more detailed information or 383 asking to other nodes close to the alarm event). Alarm messages 384 have, obviously, strict low-latency requirements. 386 Finally, routing via battery-powered nodes may be very slowly 387 reacting if the nodes are sleeping most of the time (they could 388 appear unresponsive to the alarm detection). To ensure fast message 389 delivery and avoid battery drain, routing should be avoided via this 390 category of devices. 392 3.9. Battery-powered devices 394 For convenience and low operational costs, power consumption of 395 consumer products must be kept at a very low level to achieve a long 396 battery lifetime. One implication of this fact is that RAM memory is 397 limited and it may even be powered down; leaving only a few 100 bytes 398 of RAM alive during the sleep phase. 400 The use of battery powered devices reduces installation costs and 401 does enable installation of devices even where main power lines are 402 not available. On the other hand, in order to be cost effective and 403 efficient, the devices have to maximize the sleep phase with a duty 404 cycle lower than 10%. 406 4. Unique requirements of home automation applications 408 Home automation applications have a number of specific requirements 409 related to the set of home networking applications and the perceived 410 operation of the system. 412 4.1. Support of groupcast 414 Groupcast, in the context of home automation, is defined as the 415 ability to simultaneously transmit a message to a group of recipients 416 without prior interaction with the group members (i.e. group setup). 417 A use-case for groupcast is given in Section 3.1. 419 Broadcast and groupcast in home automation MAY be used to deliver the 420 illusion that all recipients respond simultaneously. Distant 421 recipients out of direct range may not react to the (unacknowledged) 422 groupcast. Acknowledged unicast delivery MUST be used subsequently. 424 The support of unicast, groupcast and broadcast also has an 425 implication on the addressing scheme and are outside the scope of 426 this document that focuses on the routing requirements aspects. 428 It MUST be to possible to address a group of receivers known by the 429 sender even if the receivers do not know that they have been grouped 430 by the sender. 432 4.2. Constraint-based Routing 434 Simple battery-powered nodes such as movement sensors on garage doors 435 and rain meters may not be able to assist in routing. Depending on 436 the node type, the node never listens at all, listens rarely or makes 437 contact on demand to a pre-configured target node. Attempting to 438 communicate to such nodes may require long time before getting a 439 response. 441 Other battery-powered nodes may have the capability to participate in 442 routing. The routing protocol should either share the load between 443 nodes to preserve battery or only route via mains-powered nodes if 444 possible. The most reliable routing resource may be a battery-backed, 445 mains-powered smoke alarm. 447 The routing protocol MUST support constraint-based routing taking 448 into account node properties (CPU, memory, level of energy, sleep 449 intervals, safety/convenience of changing battery). 451 4.3. Support of Mobility 453 In a home environment, although the majority of devices are fixed 454 devices, there is still a variety of mobile devices: for example a 455 multi-purpose remote control is likely to move. Another example of 456 mobile devices is wearable healthcare devices. 458 While healthcare devices delivering measurement results can tolerate 459 route discovery times measured in seconds, a remote control appears 460 unresponsive if using more than 0.5 seconds to e.g. pause the music. 462 While, in theory, all battery-powered devices and mains-powered plug- 463 in modules may be moved, the predominant case is that the sending 464 node has moved while the rest of the network has not changed. 466 The routing protocol MUST provide mobility with convergence time 467 below 0.5 second if only the sender has moved. 469 A non-responsive node can either be caused by 1) a failure in the 470 node, 2) a failed link on the path to the node or 3) a moved node. In 471 the first two cases, the node can be expected to reappear at roughly 472 the same location in the network, whereas it can return anywhere in 473 the network in the latter case. The search strategy in the routing 474 protocol will behave differently depending on this expectation. The 475 routing protocol SHOULD make use of the fact that if not being able 476 to deliver a packet, it is most likely that the sending node moved; 477 rather than a failure occurred in that node or in a link on the path 478 towards it. 480 4.4. Support of Periodical Scanning 482 The routing protocol MUST support the recognition of neighbors and 483 periodical scanning. This process SHOULD preserve energy capacity as 484 much as possible. 486 (Derived from use case 3.8. Alarm Systems) 488 4.5. Scalability 490 Looking at the number of wall switches, power outlets, sensors of 491 various nature, video equipment and so on in a modern house, it seems 492 quite realistic that hundreds of low power devices may form a home 493 automation network in a fully populated "smart" home. Moving towards 494 professional building automation, the number of such devices may be 495 in the order of several thousands. 497 Thus, the routing protocol MUST support 250 devices in a subnet. 498 The routing protocol SHOULD support 2500 devices in a subnet. 500 4.6. Convergence Time 502 A home automation Personal Area Network (PAN) is subject to various 503 instability due to signal strength variation, moving persons and the 504 like. Furthermore, as the number of devices increases, the 505 probability of a node failure also increases. 507 Measured from the transmission of a packet, the following convergence 508 time requirements apply. 510 The routing protocol MUST converge within 0.5 second if no nodes have 511 moved. 513 The routing protocol MUST converge within 2 seconds if the 514 destination node of the packet has moved. 516 4.7. Manageability 518 The ability of the home network to support auto-configuration is of 519 the utmost importance. Indeed, most end users will not have the 520 expertise and the skills to perform advanced configuration and 521 troubleshooting. Thus the routing protocol designed for home PAN MUST 522 provide a set of features including zero-configuration of the routing 523 protocol for a new node to be added to the network. From ROLL 524 perspective, zero-configuration means that a node can obtain an 525 address and join the network on its own, without human intervention. 527 The routing protocol MUST support the ability to isolate a 528 misbehaving node thus preserving the correct operation of overall 529 network. 531 5. Traffic Pattern 533 Depending on the philosophy of the home network, wall switches may be 534 configured to directly control individual lamps or alternatively, all 535 wall switches send control commands to a central lighting control 536 computer which again sends out control commands to relevant devices. 538 In a distributed system, the traffic tends to be any-to-many. In a 539 centralized system, it is a mix of any-to-one and one-to-many. 541 Wall switches only generate traffic when activated, which typically 542 happens from a one to tens of times per hour. 544 Remote controls have a similar transmit pattern to wall switches, but 545 are activated more frequently. 547 Temperature/air pressure/rain sensors send frames when queried by the 548 user or can be preconfigured to send measurements at fixed intervals 549 (typically minutes). Motion sensors typically send a frame when 550 motion is first detected and another frame when an idle period with 551 no movement has elapsed. The highest transmission frequency depends 552 on the idle period used in the sensor. Sometimes, a timer will 553 trigger a frame transmission when an extended period without status 554 change has elapsed. 556 All frames sent in the above examples are quite short, typically less 557 than 5 bytes of payload. Lost frames and interference from other 558 transmitters may lead to retransmissions. In all cases, 559 acknowledgment frames with a size of a few bytes are used. 561 6. Open issues 563 Other items to be addressed in further revisions of this document 564 include: 566 o Load Balancing (Symmetrical and Asymmetrical) 568 o Security 570 7. Security Considerations 572 Encryption can be employed to provide confidentiality, integrity and 573 authentication of the messages carried on the wireless links. Adding 574 these capabilities to the ROLL devices will degrade energy efficiency 575 and increase cost, so a trade-off must be made for each specific 576 application. 578 Door locks, alarm sensors and medication dosage equipment are 579 examples where strong encryption and authentication are needed. The 580 command to unlock a door must be authenticated, as must the 581 communication between an alarm sensor and the central alarm 582 controller. Furthermore, traffic analysis of the alarm system 583 communication must not reveal if the alarm is activated. 585 Light dimmers, window shades, motion sensors, weight sensors etc. may 586 not need encryption. 588 Protection against unintentional inclusion in neighboring networks 589 must be provided. Providing confidentiality, integrity and 590 authentication against malicious opponents is optional. 592 8. IANA Considerations 594 This document includes no request to IANA. 596 9. Acknowledgments 598 J. P. Vasseur, Jonathan Hui, Eunsook "Eunah" Kim, Mischa Dohler and 599 Massimo Maggiorotti are gratefully acknowledged for their 600 contributions to this document. 602 This document was prepared using 2-Word-v2.0.template.dot. 604 10. References 606 10.1. Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 10.2. Informative References 613 Author's Addresses 615 Anders Brandt 616 Zensys, Inc. 617 Emdrupvej 26 618 Copenhagen, DK-2100 619 Denmark 621 Email: abr@zen-sys.com 623 Giorgio Porcu 624 Telecom Italia 625 Piazza degli Affari, 2 626 20123 Milan 627 Italy 629 Email: giorgio.porcu@guest.telecomitalia.it 631 Intellectual Property Statement 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use of 645 such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository at 647 http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights that may cover technology that may be required to implement 652 this standard. Please address the information to the IETF at 653 ietf-ipr@ietf.org. 655 Disclaimer of Validity 657 This document and the information contained herein are provided on an 658 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 659 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 660 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 661 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 Copyright Statement 667 Copyright (C) The IETF Trust (2008). 669 This document is subject to the rights, licenses and restrictions 670 contained in BCP 78, and except as set forth therein, the authors 671 retain all their rights. 673 Acknowledgment 675 Funding for the RFC Editor function is currently provided by the 676 Internet Society.