idnits 2.17.1 draft-greene-ss7-arch-frame-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-greene-ss7-arch-frame-00', but the file name used is 'draft-greene-ss7-arch-frame-01' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 655 lines 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.) ** There are 89 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 419 has weird spacing: '...gateway term...' == Line 493 has weird spacing: '...gateway term...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '4' on line 537 looks like a reference -- Missing reference section? '5' on line 540 looks like a reference -- Missing reference section? 'SG' on line 296 looks like a reference -- Missing reference section? 'MC' on line 480 looks like a reference -- Missing reference section? 'MG' on line 187 looks like a reference -- Missing reference section? '12' on line 566 looks like a reference -- Missing reference section? '13' on line 570 looks like a reference -- Missing reference section? '1' on line 525 looks like a reference -- Missing reference section? '2' on line 529 looks like a reference -- Missing reference section? '3' on line 533 looks like a reference -- Missing reference section? '6' on line 544 looks like a reference -- Missing reference section? '7' on line 547 looks like a reference -- Missing reference section? '8' on line 551 looks like a reference -- Missing reference section? '9' on line 555 looks like a reference -- Missing reference section? '10' on line 559 looks like a reference -- Missing reference section? '11' on line 563 looks like a reference -- Missing reference section? 'SA' on line 478 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Fernando Cuervo 2 Category: Standards Track Nancy Greene 3 Title: Nortel(Northern Telecom) 4 Date: July 1998 Matt Holdrege 6 Expires: January 1999 Ascend Communications 7 Lyndon Ong 8 Bay Networks 9 Christian Huitema 10 Bellcore 12 SS7-Internet Interworking - Architectural Framework 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 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 material 25 or to cite them other than as "work in progress." 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 30 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 31 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 Abstract 35 This document describes an architectural framework for SS7-Internet 36 interworking, onto which existing protocols and future protocols in this 37 space can be mapped. It also provides an ordering of importance for the 38 standardization of these protocols. 40 Table of Contents 42 1.0 Introduction 43 2.0 Terminology 44 3.0 Base Configurations 45 3.1 A Reference Architecture 46 3.2 Dial-up Access Configuration 47 3.2.1 SS7 Dial-Up Access Configuration 48 3.2.2 Alternate Architecture for SS7 Dial-Up Access Configuration 49 3.2.3 Comparing Approaches 50 3.3 VoIP Transit Configuration 51 3.4 ISUP and TCAP Signalling over IP 52 3.5 Transport of SS7 Signalling (ISUP+TCAP) over IP 53 4.0 Next Steps 54 5.0 References and related work 55 6.0 Authors 57 1.0 Introduction 59 This architecture document covers subject terminology and defines at a high 60 level a set of individual scenarios for SS7-Internet interworking. These 61 scenarios include dial-up internet access, Voice over IP transit, and 62 transport 63 of SS7 signaling over IP. It then proposes a series of steps for 64 standardization. 66 2.0 Terminology 68 The following functions are commonly identified in related work [4,5]: 70 Call Controller: 71 A Call Controller introduces an open interface between a 72 Signalling Gateway and a Signalling Agent/Media Gateway Controller, allowing 73 the 74 Signalling Agent to access the SS7 network through multiple redundant 75 interfaces, e.g. the classic "quad" configuration of SS7 networks. A Call 76 Controller encompasses both a Signalling Agent and a Media Gateway 77 Controller. 79 Media Gateway (MG): 80 A MG terminates PSTN facilities (trunks, loops), packetizes the media stream 81 for 82 IP, if it is not already packetized, and delivers packetized traffic to the 83 IP network. Examples of MGs are NAS (Network Access Servers) and VoIP 84 gateways. The NAS and VoIP functions may or may not be combined in one 85 gateway. 87 Media Gateway Controller (MC): 88 An MG handles the registration and management of resources at the MG. The 89 MC 90 may have the ability to authorize resource usage based on local policy, for 91 example, based on the attributes of both the end-user and the ISP. NAS 92 Controllers [5], for instance, provide MC functionality. 94 Network Access Server (NAS) Controller: 95 A NAS Controller allocates and deallocates resources according to some 96 resource 97 policy. A NAS Controller may control many NAS. It may share a server 98 platform 100 with Authentication/Authorization/Accounting (AAA) server 101 functions and/or 102 proxies to other AAA Servers. A NAS Controller encompasses both a Signalling 104 Gateway and a Media Gateway Controller. 106 Service Control Point (SCP): 107 This is a node in an SS7 network that provides centralized service logic and 109 data, such as call routing information. 111 Signal Transfer Point (STP): 112 This is a node in an SS7 network that routes signalling messages based on 113 their 114 destination address in the SS7 network 116 Signalling Agent (SA): 117 An SA realizes the signalling mediation function within the IP network, for 118 instance, for MG-to-MG, MG-to-SG, and SG-to-SG interworking. A "Call Agent" 119 in [4] includes an instance of an SA. 121 Signalling Gateway (SG): 122 An SG is a signalling agent that receives/sends PSTN native signalling at 123 the 124 edge of the IP network. The SG function may relay, translate or terminate 125 SS7 126 signaling in an SS7-Internet Gateway. 128 Other Servers (OS): 129 Other servers provide address translations, feature information, 130 authentication 131 services. IN-SCPs and RADIUS servers are instances of OS. 133 Depending on the document, the functions MG, MC, SA, SG and OS are grouped 134 into 135 nodes such as an SS7 Gateway, NAS Controller, Call Controller, Call Agent, 136 VoIP 137 gateway or NAS as discussed below. 139 3.0 Base Configurations 141 SS7-Internet interworking today covers dial-up access and VoIP applications. 143 This section presents base configurations that serve to illustrate the open 144 interfaces in the architecture, labeled by ----O----- in the figures below. 146 The figures also illustrate possible groupings of the functions enumerated 147 above, and propose an ordering of importance for standardization of the 148 protocols (the ordering of the figures implies an ordering of importance). 150 Currently several schemes are proposed for communication between a SG, MC, 151 and 152 MG. To allow these different functions to be encompassed in boxes that can 153 communicate even when the boxes are manufactured by different companies, 154 standard protocols are required. The sooner this occurs, the better. Thus, 155 the 156 highest priority of work should be to standardize the protocol for PSTN 157 native 158 signalling between the SG and MC/MG functions (section 3.2). However, there 159 are 160 other areas of work that may be addressed. These are covered in sections 161 3.3, 162 3.4 and 3.5. 164 3.1 A Reference Architecture 165 PSTN IP Network PSTN 166 +----+ 167 +---+ |IP | 168 |SCP| . . . . . . . . . . . . .|database. . . . . . . . 169 +---+\ . . . +----+ . . . 170 \ .+---+ . . . . . 171 \---|STP|------SS7--------. [SG] [SG] .--------- . 172 .+---+ . . [MC] [MC] . . . 173 . . . . . . 174 . +---+ . . . . . 175 . |CO |---------------. [MG] [MG] .--------- . 176 . /+---+ . . . . . . . . .\. 177 |----------/. . . . . . . . . . . .+-----+. . /\ 178 /\ |IP | telephone 179 telephone |phone| 180 +-----+ 181 Notes: 182 - SG, MC, and MG are functions that can be arranged in many ways with the IP 184 network. For example, [SG] and [MC] can be an SS7 gateway and/or NAS 185 controller, 186 co-located or separate, and [MC] on its own can be a call controller, and 187 [MG] 188 can be a Network Access Server (NAS) or VoIP Gateway 189 - IP database is any database accessible over IP 190 - CO is a central office, or PSTN switch, 191 - communication between MGs and SG/MCs may depend on whether the 192 communication 193 is for dial-up access or VoIP 195 Figure 1: Reference Architecture 197 Signaling System 7 (SS7) networking is the primary means used in the PSTN 198 for 199 control of circuit-switched connections and value added PSTN services such 200 as 201 freephone (800/888) number translation, calling card validation and 202 Intelligent 203 Network services. An architecture that includes a Signalling Gateway 204 provides a 205 scalable method of supporting interworking between SS7 network elements and 206 Internet elements such as a Network Access Server (NAS), or media gateway. 207 By 208 accessing the telecom network with SS7, data network elements fit cleanly 209 into 210 the telecom network infrastructure as peer switches and control points and 211 can 212 exchange information with telecom network elements for cleaner routing and 213 treatment of connections. [12, 13] provide more information on SS7. 215 The initial application of SS7 interconnection is to allow Internet access 216 points such as a media gateway to appear to the telecom network as a peer 217 telecom switch, for purposes of terminating calls for dial-up Internet 218 access. 219 Future applications include allowing exchange of information between more 220 general nodes within PSTN and Internet, such as a PSTN SCP and an Internet 221 telephony service (VoIP), or a PSTN switch and an Internet information 222 server, 223 such as a directory. 225 3.2 Dial-up Access Configuration 227 3.2.1 SS7 Dial-Up Access Configuration 229 Figure 2 is a simplified description of an SS7 dial-up access configuration. 231 Details related to end-user authentication have been left out for the sake 232 of 233 clarity. 235 +--------------+ 236 | | 237 --SS7--------> [SG/MC] | 238 | | | 239 | | | SS7 Signalling Gateway/ 240 +------|----- -+ NAS Controller 241 | 242 O 243 | 244 | 245 +------|--------+ 246 | +----[SA]| 247 | | | 248 | ([MC]) | 249 | | | 250 ---IP/dial-up->[MG] -----IP/tunnel-- > 251 | | | 252 |[SA-tunnel sig]| 253 | | 254 +---------------+ NAS 256 Figure 2: SS7 dial-up access configuration 258 The architecture in figure 2 has one open interface. Today, two alternatives 259 for 260 this protocol are represented by products in the industry. On one hand, 261 [1,2,3] 262 advocate an architecture in which some of the MC resource management 263 function 264 resides in the NAS, and some MC functions such as registration reside in the 266 Signaling Gateway. [1,2,3] propose a Q.931-based protocol for the interface 268 between Signaling Gateway and NAS. On the other hand, [5] integrates the 269 entire 270 MC function in the SG, and removes it from the MG. [5] proposes the use of 271 DIAMETER [6,7,8,9,10,11] extensions for the open interface. 273 A typical call flow for figure 2 would be the following. An SS7 message 274 arrives 275 at the SG/MC from the PSTN, initiating call setup. The SG/MC translates 276 this 277 into notification to the NAS SA of the call request and the trunk to be used 278 for 279 the incoming call. The NAS MG then terminates the media stream arriving on 280 the 281 trunk and packetizes the data for the IP network. The NAS determines the IP 283 destination for the data, either through internal means or from information 284 that 285 the SG/MC provides. 287 3.2.2 Alternate Architecture for SS7 Dial-Up Access Configuration 289 An alternate architecture (figure 3) is to separate the NAS controller and 290 Signalling Agent functions from the Signalling Gateway and to place them in 291 a 292 Call Controller. 294 +--------------+ 295 | | 296 --SS7--------> [SG] | 297 | | | 298 | | | SS7 Signalling Gateway 299 +------|----- -+ 300 | 301 O 302 | 303 +------|-------+ 304 | | | 305 | [SA/MC] | 306 | | | Call Controller/ 307 | | | NAS Controller 308 +------|----- -+ 309 | 310 O 311 | 312 +------|--------+ 313 | | | 314 | ([MC]) | 315 | | | 316 ---IP/dial-up->[MG] -----IP/tunnel-- > 317 | | 318 +---------------+ NAS 320 Figure 3: SS7 dial-up access configuration, with a separate call 321 controller 323 This alternate architecture is assumed in [4]. It presents two open 324 interfaces, 325 one between the Signalling Gateway and the Call Controller, and a second one 327 between the Call Controller and the NAS. An open interface between SG and 328 SA 329 allows an SA to access the SS7 network through multiple redundant 330 interfaces, 331 e.g. the classic "quad" configurations of SS7 networks. 333 3.2.3 Comparing Approaches 335 While the highest priority of work should be to standardize the protocol for 337 PSTN native signalling between SG and MC/MG functions, discussion should 338 take 339 into account the other functions in the architecture that are required to 340 provide working services. The three approaches identified above can be 341 compared 342 as follows: 344 1- Q.931+ extensions [1,2,3] follow a standard protocol for call signalling 345 messaging and add new messages for resource control, configuration, and SS7 346 maintenance procedures such as busying of trunks and channels, graceful and 347 abrupt shutdown of trunks, and continuity testing. 349 2- Use of a protocol framework such as Diameter with resource control 350 extensions 351 [6,7,8,9,10,11], or a similar suite of protocols [IPDC-TAC internet-draft - 352 to be provided], adds generic support of other functions such as security, 353 end-user authentication extensions, dynamic association of SG and MC to MGs, 355 etc. 357 3- Use of an open interface between SG and SA, based for example on some 358 form of 359 transport of ISUP over IP, combined with the protocol proposed in [4], 360 allows 361 to concentrate all call-state in a Call Controller, enables calls to survive 363 the failure of an individual SG, and provides for compatibility with VoIP 364 solutions. 366 3.3 VoIP Transit Configuration 368 VoIP transit adds new requirements to the architecture. For example, there 369 will 370 be more than one VoIP gateway involved in a call, and possibly even more 371 than 372 one call controller or equivalent. One approach is that documented in [4]. 374 Figure 4 is a simplified description of a VoIP transit application as found 375 in 376 [4]. This configuration shows a potential open interface between the 377 Signalling 378 Gateway and a Call Controller. This may not be necessary if the Call 379 Controller 380 and SS7 Gateway are implemented in one system. 382 Note that a Call Controller interworks with a second VoIP MG to complete a 383 call, 384 and this may or not be through a second Call Controller (see section 3.4). 386 In fact, the architecture described here is just one of perhaps many that 387 could 388 be used to provide VoIP transit. 390 SS7 gateway 391 +--------------+ 392 | | 393 SS7<--------->[SG] | 394 (ISUP) | | | 395 | | | 396 +------|-------+ 397 ISUP/IP or | 398 internal O 399 | 400 | 401 call controller| 402 +-------|-------+ 403 | [SA] | 404 | | | 405 | [MC] | 406 | | \ | 407 +-------|--\----+ 408 | \ 409 O \-----------O-------------\ 410 | | 411 +-------|----------+ +-----------|-----+ 412 | | | | | | 413 | | | | | | 414 <-IMT------->[MG]<---------RTP stream------>[MG]<-------IMT-----> 415 | | | | | | 416 | [SA-user sig] | | [SA-user sig] | 417 | | | | 418 +------------------+ +-----------------+ 419 originating VoIP gateway terminating VoIP gateway 421 Notes: 422 - IMT is Inter-Machine Trunk 424 Figure 4: VoIP Transit Configuration 426 The call flow for figure 4 is similar to that for figure 2. For VoIP 427 however, 428 the Call Controller has the extra work of finding and then alerting the 429 terminating VoIP gateway of the call. 431 3.4 ISUP and TCAP Signalling over IP 433 In this section, scenarios involving both SS7 TCAP (Transaction 434 Capabilities) 435 and ISUP (ISDN User Part) signaling over IP are described. 437 TCAP signaling within IP networks may be used for access to a database. In 438 the 439 VoIP case the database could be available from the Call Controller. In a NAS 441 dial-up access case, it could be available from the Signalling Gateway/NAS 442 Controller. Alternatively, the Signaling Gateway may provide access from SS7 444 network systems to an IP database (terminating TCAP), or may provide access 445 to 446 SS7 network databases from an IP system (originating TCAP), subject to 447 services 448 supported by the SS7 network. 450 ISUP signaling within IP networks may be used in the context of VoIP. If 451 more 452 than one Call Controller is used by an implementation of VoIP, then an open 453 interface between Call Controllers needs to be considered. This interface 454 could 455 be supported by extensions to SS7 ISUP (ISDN User Part) protocol, carried 456 over 457 IP (see section 3.5). However, non-SS7 protocols such as H.323 (ITU-T SG16) 458 and 459 SIP (IETF mmusic) may also apply to this interface. See figure 5. 461 +--------------+ 462 SS7 ----->| SCP-Database | 463 (TCAP)/ +--|-----------+ 464 / | 465 SS7 gateway O | SS7 gateway 466 +--------|-----+ | +--------------+ 467 | v | | | | 468 SS7<---------->[SG] | | | [SG]<---------> SS7 469 (ISUP) | | \ | O | | | (ISUP) 470 | | | | | | | | 471 +------|---|---+ | +------|-------+ 472 ISUP/IP or | | / | 473 internal | | / | 474 O O TCAP/ O 475 originating | | IP / | terminating 476 call controller| | / | call controller 477 +-------|--/---/+ +-----|--------+ 478 | [SA]---/ | ISUP+/IP or | [SA] | 479 | | \----------O-------------/ | | 480 | [MC] |intergatekeeper| [MC] | 481 | | | protocol | | | 482 +-------|-------+ +-----|--------+ 483 O O 484 | | 485 +-------|----------+ +----------|------+ 486 | | | | | | 487 | | | | | | 488 <-IMT-------->[MG]<---------RTP stream----->[MG]<--------IMT--> 489 | | | | | | 490 | [SA-user sig] | | [SA-user sig] | 491 | | | | 492 +------------------+ +-----------------+ 493 originating VoIP gateway terminating VoIP gateway 495 Notes: 496 - IMT is Inter-Machine Trunk 498 Figure 5: ISUP/TCAP Signalling over IP in a particular VoIP 499 Transit Configuration with >1 Call Controller 501 3.5 Transport of SS7 Signalling (ISUP+TCAP) over IP 503 SS7 utilizes its own message transport protocol and has defined performance 504 requirements. Supporting SS7 signaling at the SS7 Gateway or within IP 505 networks 506 requires transport of signaling over IP. 508 4.0 Next Steps 510 This document provides a framework to identify the open interfaces that are 511 relevant to introduce useful services that have SS7-Internet interworking as 512 a 513 major component. From the ordering of the figures in section 3, it proposes 514 an 515 ordering of importance for standardization of the protocols. 517 The goal of an SS7-Internet working group would be to decide which protocols 518 are 519 to be standardized, with what priority, and the functionality necessary in 520 each 521 protocol. 523 5.0 References and related work 525 [1] R. Dalias, J. Matousek, L. Ong, "Bay Networks SS7-Internet Gateway 526 Architecture", draft-ong-ss7-internet-gateway-01.txt, May 1998, work in 527 progress 529 [2] J. Matousek, L. Ong, "Bay Networks SS7-Internet Access Signaling 530 Protocol", 531 draft-long-ss7-signal-00.txt, June 1998, work in progress 533 [3] M. Holdrege, "The Reliable Signaling Gateway Control Protocol", 534 draft-rfced- 535 info-holdrege-00.txt, June 1998, work in progress 537 [4] M. Arango, C. Huitema, Simple Gateway Control Protocol (SGCP), draft- 538 huitema-sgcp-v1-00.txt, May 1998, work in progress 540 [5] F. Cuervo, N. Greene, "Best Current Practice for Modem Outsourcing", 541 draft- 542 greene-nasreq-00.txt, March 1998, work in progress 544 [6] P. R. Calhoun, G. Zorn, P. Pan, "Diameter Framework Document", draft- 545 calhoun-diameter-framework-00.txt, May 1998, work in progress 547 [7] P. R. Calhoun, A. Rubens, "Diameter Base Protocol", 548 draft-calhoun-diameter- 549 03.txt, April 1998, work in progress 551 [8] P. R. Calhoun, N. Greene, "Diameter Resource Management Extensions", 552 draft- 553 calhoun-diameter-res-mgmt-01.txt, May 1998, work in progress 555 [9] N. Greene, F. Cuervo, "Diameter SS7 Session Setup Extensions", 556 draft-greene- 557 diameter-ss7-session-00.txt, July 1998, work in progress 559 [10] P. R. Calhoun, W. Bulley, "Diameter User Authentication Extensions", 560 draft- 561 calhoun-diameter-authent-03.txt, April 1998, work in progress 563 [11] S. A. Vakil, P. R. Calhoun, "Diameter IP Security Policy extensions", 564 draft-calhoun-diameter-ipsec-policy-00.txt, March 1998, work in progress 566 [12] ITU-T Recommendation Q.700, "Introduction to CCITT Signalling System 567 No. 568 7", March, 1993 570 [13] ITU-T Recommendation Q.1600, "Signalling System No.7 - Interaction 571 between 572 ISUP and INAP", September, 1997 574 [IPDC-TAC internet-draft] - to be provided 576 6.0 Authors 578 Fernando Cuervo 579 Nortel 580 Ottawa, ON, Canada 581 Phone: 613-763-4628 582 Email: cuervo@nortel.ca 584 Nancy Greene 585 Nortel 586 Ottawa, ON, Canada 587 Phone: 613-763-9789 588 Email: ngreene@nortel.ca 590 Matt Holdrege 591 Ascend Communications 592 1701 Harbor Bay Pkwy 593 Alameda, CA 94502 594 Phone: 510-769-6001 595 Email: matt@ascend.com 597 Christian Huitema 598 Bellcore 599 445 South Street, 1J236B 600 Morristown, NJ 07960 601 Email: huitema@bellcore.com 603 Lyndon Ong 604 Bay Networks, Inc. 605 4401 Gt America Pkwy 606 Santa Clara, CA 95052 607 Email: long@baynetworks.com 609 Full Copyright Statement 611 Copyright (C) The Internet Society (1998). All Rights Reserved. 613 This document and translations of it may be copied and furnished to 614 others, and derivative works that comment on or otherwise explain it 615 or assist in its implementation may be prepared, copied, published 616 and distributed, in whole or in part, without restriction of any 617 kind, provided that the above copyright notice and this paragraph are 618 included on all such copies and derivative works. However, this 619 document itself may not be modified in any way, such as by removing 620 the copyright notice or references to the Internet Society or other 621 Internet organizations, except as needed for the purpose of 622 developing Internet standards in which case the procedures for 623 copyrights defined in the Internet Standards process must be 624 followed, or as required to translate it into languages other than 625 English. 627 The limited permissions granted above are perpetual and will not be 628 revoked by the Internet Society or its successors or assigns. 630 This document and the information contained herein is provided on an 631 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 632 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 633 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 634 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 635 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.