idnits 2.17.1 draft-jspark-mmcp-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.3 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 621. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 563, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 572, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 576, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 580, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jae Sung Park 2 Intended status: Informational Kyungpook National University 3 Expires: November 2007 Seok Joo Koh 4 May 21, 2007 Kyungpook National University 6 MMCP for IP Multicast in Mobile Networks 7 draft-jspark-mmcp-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 This document may only be posted in an Internet-Draft. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on November 21, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document is a part of the ITU-T Recommendation and ISO/IEC 47 International Standard, named the Mobile Multicast Communications 48 Protocol (MMCP). The MMCP is a protocol that can be used to support a 49 variety of multimedia multicasting services in the IP-based wireless 50 mobile networks. The MMCP is targeted at the real-time one-to-many 51 multicast services and applications over mobile communications 52 networks. 54 Internet Draft Jae Sung Park 55 Intended status: Informational Kyungpook National University 56 Expires: November 2007 Seok Joo Koh 57 May 21, 2007 Kyungpook National University 59 Conventions used in this document 61 In examples, "C:" and "S:" indicate lines sent by the client and 62 server respectively. 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119. 68 Table of Contents 70 1. Introduction...................................................5 71 2. Terminology....................................................5 72 2.1. Abbreviations.............................................5 73 2.2. Conventions...............................................6 74 3. Protocol Overview..............................................6 75 4. Design Considerations..........................................7 76 4.1. Design Principles.........................................7 77 4.2. Functional Entities.......................................8 78 4.2.1. Mobile Node (MN).....................................8 79 4.2.2. Multicast Contents Server (MCS)......................8 80 4.2.3. Session Manager (SM).................................8 81 4.2.4. Local Mobility Controller (LMC)......................8 82 5. Packets........................................................9 83 5.1. Base Header...............................................9 84 5.2. Packet Formats...........................................10 85 6. Procedures....................................................11 86 6.1. Session Join.............................................11 87 6.2. User Leave...............................................12 88 6.3. Status Monitoring........................................12 89 6.4. Mobility Support.........................................13 90 7. Security Considerations.......................................13 91 8. IANA Considerations...........................................13 92 9. Conclusions...................................................13 93 10. Acknowledgments..............................................13 94 APPENDIX A: Timers...............................................14 95 A.1. JWT (Join Waiting Time)..................................14 96 A.2. SGT (Status Report Generation Time)......................14 97 A.3. SPT (Status Probe Time)..................................14 98 A.4. HWT (Handover Waiting Time)..............................14 99 A.5. RXT (Retransmission Time)................................14 100 11. References...................................................16 101 11.1. Normative References....................................16 102 11.2. Informative References..................................16 103 Author's Addresses...............................................16 104 Intellectual Property Statement..................................16 105 Disclaimer of Validity...........................................17 107 Internet Draft Jae Sung Park 108 Intended status: Informational Kyungpook National University 109 Expires: November 2007 Seok Joo Koh 110 May 21, 2007 Kyungpook National University 112 1. Introduction 114 This document is a part of the ITU-T Recommendation and ISO/IEC 115 International Standard, named the Mobile Multicast Communications 116 Protocol (MMCP). The MMCP is a protocol that can be used to support a 117 variety of multimedia multicasting services in the IP-based wireless 118 mobile networks. The MMCP is targeted at the real-time one-to-many 119 multicast services and applications over mobile communications 120 networks. 122 In MMCP, Session Manager is at the heart of multicast communications. 123 It is responsible for overall control by governing the session join 124 and handover support operations. 126 The MMCP has a characteristic as follows. The MMCP operates on the 127 IP-based network. The MMCP easy integrates the existing IP-based 128 schemes and protocols required for realization of the MMC services. 129 And MMCP has separation of the control channel from the data channel. 131 Copyright (C) The IETF Trust (2007). This version of this MIB module 132 is part of RFC XXXX; see the RFC itself for full legal notices. 134 Copyright (C) The IETF Trust (2007). The initial version of this MIB 135 module was published in RFC XXXX; for full legal notices see the RFC 136 itself. Supplementary information may be available at: 137 http://www.ietf.org/copyrights/ianamib.html. 139 2. Terminology 141 2.1. Abbreviations 143 AAA Authentication, Authorization, and Accounting 145 AP Access Point 147 AS Authentication Server 149 IGMP Internet Group Management Protocol 150 IP Internet Protocol 152 LMC Local Mobility Controller 154 MCS Multicast Contents Server 156 MLD Multicast Listener Discovery 158 MMC Mobile Multicast Communications 160 MMCF MMC Framework 162 MN Mobile Node 164 PoA Point of Attachment 166 SM Session Manager 168 WiBro Wireless Broadband 170 WLAN Wireless Local Area Network 172 2.2. Conventions 174 In this document, the capital characters are used to represent a 175 packet of MMCP (e.g., SJR for Session Join Request packet), and the 176 capital and italic characters are used for timer used in MMCP (e.g., 177 JWT for Join Waiting Timer). 179 3. Protocol Overview 181 The MMCP is Mobile Multicast Control Protocol, which is based on the 182 Mobile Multicast Communications Framework (MMCF). MMCP designed to 183 support one-to-many multicast applications running over multicast- 184 capable networks. MMCP operates over IPv4/IPv6 networks that have the 185 IP multicast forwarding capability with the help of IGMP and IP 186 multicast routing protocols. MMCP considers real-time service and 187 handover schemes. MMCP could possibly be provisioned over UDP or TCP. 189 + + 190 +--------------------------------+ 191 | | Multicast Applications | | 192 +----------------+ + 193 | | MMCP | | | 194 +----------------+---------------+ 195 | | UDP | | 196 +--------------------------------+ 197 | | IP | | 198 +--------------------------------+ 199 | | 200 Control Channel Data Transport Channel 202 Figure 1. MMCP Protocol Model 204 A Multicast Contents Server (MCS) transmits multicast data to many 205 Mobile Nodes (MNs) using the legacy UDP/IP multicasting. For the 206 control purpose of the multicast data transport, a MMCP session is 207 established between a Session Manager (SM) and MNs, possibly with one 208 or more Local Mobility Controllers (LMCs) between SM and MNs. The SM 209 is used to perform the overall control operations for the MMCP 210 session, and it shall be interworking with MCS. The LMC is used to 211 locally control a part of MNs participating in the session, which is 212 for scalability enhancement of the MMCP operations. Each MN 213 represents a receiving user for mobile multicast applications. 215 4. Design Considerations 217 This section describes some considerations for the design of MMCP. 219 4.1. Design Principles 221 This section describes the design of the MMCP for MMC services and 222 applications over wireless mobile networks as well as the fixed 223 communications networks. For this purpose, the MMCP shall be designed 224 with the following design principles: 226 - Generic IP-based control schemes for MMC 228 - Easy integration of legacy multicast applications with MMCP 230 - Separation of the control channel from the data channel 232 - Interworking with the conventional protocols for security and 233 authentication/authorization 235 4.2. Functional Entities 237 4.2.1. Mobile Node (MN) 239 A Mobile Node represents a multicast receiving user for the mobile 240 multicast application in the MMC networks. A MN will receive the MMC 241 services from the Multicast Contents Server (MCS) in the network 242 using the MMCP. Each MN may connect to the MMC session from the 243 wireless or wired access networks. In either case, the identical MMC 244 services will be provided. 246 4.2.2. Multicast Contents Server (MCS) 248 The Multicast Contents Server is a single multicast data sender in a 249 MMC session. When a MMC session starts, the MCS will begin to send 250 the multicast data to the promising MNs in the network, using IP 251 multicast. 253 4.2.3. Session Manager (SM) 255 The Session Manager is a functional entity that performs the overall 256 control operations for a MMC session. The SM shall be interworking 257 with the corresponding MCS for the MMC session. The authentication 258 and authorization step for a newly joining MN will possibly be 259 implemented by interworking with an appropriate AAA server. 261 The SM may be implemented either on the same machine with MCS or 262 separately on the different machine. It is noted that the SM and MCS 263 perform the different functionality. SM manages the overall control 264 functionality for the MMC session, whereas the MCS is the multicast 265 sender in the data transport plane. 267 4.2.4. Local Mobility Controller (LMC) 269 For scalability of the MMC functional operations and also for any 270 reason of deployment of MMC services, one or more Local Mobility 271 Controller may be used for the session. From the functionality point 272 of view, the SM and LMC are identical during the session. 274 When a MN contacts with the SM to join a MMC session, the SM may 275 assign an appropriate LMC to the MN, after processing the session 276 join procedure. After that, the MN will now contact with the LMC 277 instead of the SM for all of the MMC control operations. 279 That is, during the session, the LMC is responsible for the control 280 operations (status monitoring and mobility support) through 281 interworking with the MNs. The monitored status information on the 282 session and MNs will be delivered to the SM. 284 5. Packets 286 A MMCP packet contains a 12-byte base header together with body 287 packets. 289 In this section, we describe a brief sketch of the MMCP packet format. 291 5.1. Base Header 293 The base header contains the following information: 295 Packet Type (8bits) 297 It indicates the type of this MMCP packet. The encoding values of the 298 MMCP packets are described in Table 1. 300 MMCP Version (4bits) 302 This field indicates the version of MMCP. At present, the value is 303 v.1 (0001). 305 MN Length (4bits) 307 This value indicates the length of the MMC user identification in 308 word. Unit of word is 4-bytes. 310 Payload Length (16bits) 312 This value indicates the total length of the body in byte, following 313 the base header. 315 Error Code (6bits) 317 It is an error code bit for representation of the MMCP protocol 318 error: 320 No Error (000000) 322 Session Join Reject (000001) 324 Monitoring Error (000010) 325 Handover Error (000100) 327 N (1bit) 329 It is a flag bit for new LMC address. The use of this flag depends on 330 the packet types: 332 For the SJC (Session Join Confirm), the HIC (Handover Initiation 333 Confirm) packets, the N is set to 1 indicates that new Local Mobility 334 Controller address is exist. N is set to 0, otherwise. 336 F (1bit) 338 It is a flag bit for confirm message. The use of this flag depends on 339 the packet types: 341 For the SJC (Session Join Confirm), LJC (Local Join Confirm), ULC 342 (User Leave Confirm), HIC (Handover Initiation Confirm) packets, the 343 F is set to 1 indicates that each of the corresponding request is 344 accepted. F is set to 0, otherwise. 346 Reserved (24bits) 348 This field is reserved for future use. 350 Session ID (32bits) 352 This field is used to identify a MMCP session by the Mobile Node. It 353 may also be used to verify the session. In the session setup phase, 354 this information must first be informed by Session Manager. 356 5.2. Packet Formats 358 MMCP defines the total 15 packet types. The following table 359 summarizes the packets used in MMCP. 361 Table 1. MMCP Packets 363 +-------------------------------------------------------------------+ 364 | Full Name |Acronym | Encoding | From | To | 365 | | | Value | | | 366 +-------------------------------------------------------------------+ 367 | Session Join Request | SJR | 0000 0001 | MN | SM | 368 +-------------------------------------------------------------------+ 369 | Session Join Confirm | SJC | 0000 0010 | SM | MN | 370 +-------------------------------------------------------------------+ 371 | Local Join Request | LJR | 0000 0011 | MN | LMC | 372 +-------------------------------------------------------------------+ 373 | Local Join Confirm | LJC | 0000 0100 | LMC | MN | 374 +-------------------------------------------------------------------+ 375 | User Leave Request | ULR | 0000 0101 | MN | LMC | 376 +-------------------------------------------------------------------+ 377 | User Leave Confirm | ULC | 0000 0110 | LMC | MN | 378 +-------------------------------------------------------------------+ 379 | User Status Report | USR | 0000 0111 | MN | LMC or SM | 380 +-------------------------------------------------------------------+ 381 | Aggregation Status | ASR | 0000 1000 | LMC | SM | 382 | Report | | | | | 383 +-------------------------------------------------------------------+ 384 | Status Report ACK | SRA | 0000 1001 | LMC | MN | 385 | | | | SM | LMC or MN | 386 +-------------------------------------------------------------------+ 387 | User Status Probe | USP | 0000 1010 | LMC | MN | 388 | | | | SM | LMC or MN | 389 +-------------------------------------------------------------------+ 390 | Handover Initiation | HIR | 0000 1011 | MN | LMC or SM | 391 | Request | | | | | 392 +-------------------------------------------------------------------+ 393 | Handover Initiation | HIP | 0000 1100 | LMC | MN | 394 | Progress | | | | | 395 +-------------------------------------------------------------------+ 396 | Handover Context | HCT | 0000 1101 | Old LMC | New LMC | 397 | Transfer | | | | | 398 +-------------------------------------------------------------------+ 399 | Handover Transfer ACK| HTA | 0000 1110 | New LMC | Old LMC | 400 +-------------------------------------------------------------------+ 401 | Handover Initiation | HIC | 0000 1111 | LMC or SM | MN | 402 | Confirm | | | | | 403 +-------------------------------------------------------------------+ 405 6. Procedures 407 6.1. Session Join 409 Session Join is procedure that MN receives multicast content from MCS. 410 After Session Join procedure is divided into two scenarios. It is 411 that either LMC exist or not. 413 First of all, the scenario is that LMC exist as follow. MN sends a 414 SJR message to the SM for Session Join. When the SM receives the SJR 415 message, the SM identifies an authenticated user from Authentication 416 Server (AS) and database. Authentication processing is used by AS and 417 DB, which is out of scope. 419 If MN is an authenticated user, the SM sends a SJC message that 420 includes setting f flag to 1 at base header of packet and MCS, LMC 421 information at body of packet. The MN sends a LJR message to address 422 of received LMC. After join processing, the LMC sends corresponding 423 LJC message to MN. This procedure finishes a Session Join. If MN is 424 not an authenticated user, the SM sends a SJC message that includes 425 setting f flag to 0 at base header packet only. The Session Join 426 procedure is operating Join Waiting Time (JWT). The Session Join 427 procedures shall be finished until JWT timer is expired. If JWT timer 428 is expired, MN considers that Session Join procedure is failed. 430 6.2. User Leave 432 User Leave is procedure that user leave session when receives content. 433 MN sends an ULR message to LMC. After leave processing, the LMC sends 434 an ULC message to MN. 436 6.3. Status Monitoring 438 Status Monitoring is procedure for identifying status of the MNs or 439 LMCs and checking the handover information. And it sends QoS 440 information to upper controller. Status Monitoring is classified two 441 scenarios, LMC exist and LMC does not exist. 443 First of all, the scenario is that LMC exist as follow. MN sends an 444 USR message to the LMC for Status Monitoring. The MN sends 445 periodically the USR message to the LMC by Status Report Generation 446 Time (SCT) of the MN. When the LMC receives the USR message, the LMC 447 sends a SRA message to the MN for response. 449 In order to SM has information of MNs, the LMC sends an ASR message 450 to the SM. The ASR message is aggregated with information of MNs. The 451 LMC also sends periodically the ASR message to the SM by SGT timer of 452 the LMC. When the SM receives the ASR message, the SM sends a SRA 453 message to the LM for response. 455 The LMC and SM operate Status Probe Time (SPT). If the LMC does not 456 receive an USR message from the MN or the SM does not receive an ASR 457 message from the LMC by expired SPT timer, the LMC or SM will send 458 the USP message to the MN or LMC. If the responding USR or ASR 459 message has not arrived until RXT timer expires, the LMC or SM 460 retransmit USR or ASR message. The MN or LMC regards termination, if 461 MN or LMC does not response for four sending USR or ASR message. 463 6.4. Mobility Support 465 In handover operation, the MN will send a HIR message to old LMC and 466 waits for the HIC message until the Handover Waiting Time (HWT) 467 expires. The old LMC sends a HIP message to the MN and finds new LMC 468 for the information of the MN to transmit. The old LMC sends a HCT 469 message to new LMC and waits for the HTA message until the RXT timer 470 expires. The new LMC updates transmitted information of the MN from 471 old LMC, and then sends a HTA message to old LMC. The old LMC 472 receives the HTA message, then sends the HIC message to the MN if the 473 responding HIC message has not arrived until HWT timer expires, the 474 MN may send the HIR message again. And if the responding HTA message 475 has not arrived until RXT timer expires, the old LMC may send the HCT 476 message again. 478 The MN will send a LJR message to the new LMC and waits for the LJC 479 message until the RXT timer expires. When the new LMC received the 480 LJR message, the new LMC sends an ASR message to the SM at next 481 transmission time. The SM updates modified information of the new LMC, 482 and then sends a SPA message to the new LMC. 484 7. Security Considerations 486 TBD 488 8. IANA Considerations 490 TBD 492 9. Conclusions 494 This document describes the Mobile Multicast Communications Protocol 495 (MMCP). The MMCP is a protocol that can be used to support a variety 496 of multimedia multicasting services in the IP-based wireless mobile 497 networks. The MMCP is targeted at the real-time one-to-many multicast 498 services and applications over mobile communications networks. The 499 MMCP benefits are that the MMCP is integrated with legacy multicast 500 applications and used for separation the control channel from the 501 data channel. 503 10. Acknowledgments 505 This document was prepared using 2-Word-v2.0.template.dot. 507 APPENDIX A: Timers 509 This appendix summarizes the timers used for MMCP for information. 511 A.1. JWT (Join Waiting Time) 513 The JWT timer is used for session join procedures. When session 514 starts, MN will send a SJR packet to the SM. and the MN waits for the 515 SJC packet until the JWT timer expires. If LMC exist, MN will send a 516 LJR packet to the LMC. And the MN waits for the LJC packet until the 517 JWT timer expires. When the timer expires and the corresponding 518 packet has not arrived until then, it may consider that session join 519 procedure is failed. 521 A specific value of JWT timer depends on the implementation. 523 A.2. SGT (Status Report Generation Time) 525 Each MN or LMC transmits the USR packet to its upper system every SGT 526 timer. If upper system does not receive the USR packet, upper system 527 will send an USP packet to the lower system. 529 A specific value of SGT timer depends on the implementation. 531 A.3. SPT (Status Probe Time) 533 An USP packet is message that LMC or SM checks MN or LMC alive. If 534 the USR packet does not receive until SPT timer expires, USP packet 535 sends. 537 A specific value of SPT timer depends on the implementation. 539 A.4. HWT (Handover Waiting Time) 541 The HWT timer is used by handover packet: HIR. When handover starts, 542 MN will send HIR packet to LMC or SM. And the MN waits for the HIC 543 packet until the HWT timer expires. When the timer expires and the 544 corresponding packet has not arrived until then, it may send the HIR 545 packet again. 547 A specific value of HWT timer depends on the implementation. 549 A.5. RXT (Retransmission Time) 551 The RXT timer is used by the packet initiator to wait for the 552 corresponding confirm packet or ACK packet. For example, a joiner MN 553 sends SJR packet to SM and the MN waits for the SJC packet until the 554 RXT timer expires. When the timer expires and the confirm packet has 555 not arrived until then, it may send the request packet again. 557 A specific value of RXT timer depends on the implementation. 559 11. References 561 11.1. Normative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 11.2. Informative References 568 [1] ITU-T Recommendation X.603 (2004) | ISO/IEC 16512-1:2004, 569 Information Technology - Relayed Multicast Protocol (RMCP): 570 Framework 572 [2] ITU-T Recommendation X.603.1 | ISO/IEC 16512-2, Information 573 Technology - Relayed Multicast Protocol (RMCP): Specification 574 for Simplex Group Applications 576 [3] ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1:2002, 577 Information Technology - Enhanced Communications Transport 578 Protocol (ECTP): Specification of Simplex Multicast Transport 580 [4] ITU-T Recommendation X.606.1 (2002) | ISO/IEC 14476-2:2003, 581 Information Technology - Enhanced Communications Transport 582 Protocol (ECTP): Specification of QoS Management for Simplex 583 Multicast Transport 585 Author's Addresses 587 Jae Sung Park 588 Kyungpook National University, KOREA 589 1370 Sankyuk-dong, Buk-gu, Daegu 702-701, Korea 591 Email: knucsid@gmail.com 593 Seok Joo Koh 594 Kyungpook National University, KOREA 595 1370 Sankyuk-dong, Buk-gu, Daegu 702-701, Korea 597 Email: sjkoh@knu.ac.kr 599 Intellectual Property Statement 601 The IETF takes no position regarding the validity or scope of any 602 Intellectual Property Rights or other rights that might be claimed to 603 pertain to the implementation or use of the technology described in 604 this document or the extent to which any license under such rights 605 might or might not be available; nor does it represent that it has 606 made any independent effort to identify any such rights. Information 607 on the procedures with respect to rights in RFC documents can be 608 found in BCP 78 and BCP 79. 610 Copies of IPR disclosures made to the IETF Secretariat and any 611 assurances of licenses to be made available, or the result of an 612 attempt made to obtain a general license or permission for the use of 613 such proprietary rights by implementers or users of this 614 specification can be obtained from the IETF on-line IPR repository at 615 http://www.ietf.org/ipr. 617 The IETF invites any interested party to bring to its attention any 618 copyrights, patents or patent applications, or other proprietary 619 rights that may cover technology that may be required to implement 620 this standard. Please address the information to the IETF at 621 ietf-ipr@ietf.org. 623 Disclaimer of Validity 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 628 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 629 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 630 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Copyright Statement 635 Copyright (C) The IETF Trust (2007). 637 This document is subject to the rights, licenses and restrictions 638 contained in BCP 78, and except as set forth therein, the authors 639 retain all their rights. 641 Acknowledgment 643 Funding for the RFC Editor function is currently provided by the 644 Internet Society.