idnits 2.17.1 draft-gross-sipaq-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) ** Obsolete normative reference: RFC 2543 (ref. '1') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2327 (ref. '12') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1890 (ref. '13') (Obsoleted by RFC 3551) -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Duplicate reference: RFC2205, mentioned in '15', was also mentioned in '6'. -- Possible downref: Non-RFC (?) normative reference: ref. '17' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Gross 3 INTERNET DRAFT Intel Corporation 4 draft-gross-sipaq-00.txt 5 November, 2000 H. Sinnreich 6 Expires: May 2001 D. Rawlins 7 SIP Working Group MCI WorldCom 9 S. Thomas 10 TransNexus 12 QoS and AAA Usage with SIP Based IP Communications 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any 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 Abstract 35 This document specifies the architecture, protocols and messages for 36 SIP based IP communications between Internet domains in support of 37 QoS and AAA. Detailed message flows and message contents are 38 discussed and specified. AAA requirements including inter-domain and 39 user authorization in mobile and non-mobile environments are 40 addressed. A solution is proposed where session setup and teardown 41 are linked with QoS and AAA signaling using AAA policy servers and 42 clearinghouses. 44 Table of Contents 46 Status of this Memo................................................1 47 Abstract...........................................................1 48 Table of Contents..................................................2 49 1. Introduction....................................................3 50 2. Terminology.....................................................3 51 3. Overview........................................................4 52 4. Authorization and Authentication................................6 53 4.1. Inter-domain..................................................7 54 4.2. Application Level and Pre-call Mobility.......................9 55 5. Message Contents...............................................12 56 5.1. SIP Proxy to APS (Originating Domain)........................12 57 5.2. APS to CH (from Originating Domain)..........................12 58 5.3. CH to APS (to Originating Domain)............................13 59 5.4. APS to SIP Proxy (Originating Domain)........................13 60 5.5. SIP Proxy to SIP Proxy (Originating to Terminating Domain)...13 61 5.6. SIP Proxy to APS (Terminating Domain)........................13 62 6. Protocol Support...............................................13 63 7. Messaging Overview.............................................14 64 7.1. Originating Domain Contacts Clearinghouse....................15 65 7.2. Terminating Domain Contacts Clearinghouse....................19 66 8. Accounting, Charging and Billing...............................19 67 9. Security Considerations........................................20 68 10. Acknowledgments...............................................20 69 11. References....................................................20 70 12. Author's Address..............................................21 71 13. Full Copyright Statement......................................22 72 1. Introduction 74 Commercial grade IP communications may require voice and other media 75 transport of equal or higher quality than present 3.1 kHz circuit 76 switched voice. Conversely, lower media quality may be acceptable in 77 cases where other service advantages exist, similar to wireless 78 audio/video streaming. 80 We focus here on those circumstances where voice and other media 81 quality are important and require end-to-end network resources for 82 QoS with larger bandwidth and/or lower delay. Dynamic setup of end- 83 to-end network resources for QoS requires highly scalable mechanisms 84 to authenticate, authorize and account (AAA) for network resources 85 across the Internet. This must be able to happen between a very 86 large number of independent and various access domains that may have 87 no business or trust relationship with each other, or may not even 88 know of each other's existence before initiating end-to-end 89 communications. 91 The term IP communications is used here for a large class of new 92 communications enabled by IP and the Internet such as presence, 93 instant text, voice or multimedia conferences, the integration of 94 messaging and real time communications, the integration of 95 communications in productivity software, with transactions, games, 96 entertainment and other. Not all IP communication services can be 97 extended to other networks, such as PSTN, ISDN, H.323, BICC or the 98 so-called "softswitch" networks that use MEGACO or similar master- 99 slave signaling protocols. 101 AAA services are important because QoS and IP to PLMN and PSTN 102 termination through gateways are services that are billable. 103 Unauthorized users should be prevented from using these services and 104 service providers should be able to appropriately bill authorized 105 users. 107 This document specifies the architecture, protocols and messages for 108 SIP based IP communications between Internet domains in support of 109 QoS and AAA [1]. It builds on information presented in [2] and [3]. 110 This document discusses AAA requirements including inter-domain and 111 user authorization in mobile and non-mobile environments. One AAA 112 solution is proposed. The developments in this document assume 2 113 party call control only. The term originator implies a user who 114 initiates and participates in the IP communication session. 116 2. Terminology 118 This section defines terms used throughout this document. Some of 119 these terms may have other meanings outside the context of this 120 work. Their outside meanings are not guaranteed to coincide with the 121 definitions given here. 123 APS: AAA and Policy Server. The APS acts as a policy decision point, 124 PDP, for network usage related policies, including IP telephony 125 and QoS requests such as bandwidth reservation. The APS acts on 126 service requests, such as SIP INVITEs for calls requiring QoS 127 and possibly outsources requests to other PDPs, such as a DIR, 128 ADB, or CH. The APS renders a decision and may then apply 129 policy to network elements. 131 CH: Clearinghouse. The CH authorizes inter-domain calls with QoS 132 and collects usage reports for settlement between service 133 providers. 135 DIR: Directory. The DIR is the source for end user names and their 136 services. A DIR has the list of all individual users and some 137 attributes that the APS may use as criteria for policy 138 decisions on an individual basis. 140 ADB: Accounts Database. The ADB is part of the "back office" of the 141 service provider. The ADB contains a list of all corporate 142 accounts and the respective service level specifications that 143 apply at the edges of their networks. It may have classes of 144 policies or customized policies for various corporate accounts. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [4]. 150 3. Overview 152 The components involved in AAA and QoS enabled IP communication 153 sessions are shown in Figure 1. SP represents a SIP Proxy. The 154 clearinghouse (CH) exists outside the access domains and is 155 responsible for providing inter-domain AAA services. In some cases a 156 customer APS may exist outside the access domain. One such case may 157 be where the customer has his or her own corporate domain with a 158 corresponding corporate APS. 160 Routers internal to the domain are labeled "R" and the edge router 161 is labeled "ER". The media agent, "MA", is the application that 162 sends/receives telephony/multimedia session data. The ER may be 163 responsible for aggregating RSVP flows into appropriate Diffserv 164 classes. 166 All developments discussed in this document apply using SIP for 167 setting up IP communications. Other signaling means such as H.323, 168 MEGACO or related protocols, may have a different structure in the 169 dependency between signaling, QoS setup and AAA and are therefore 170 not the object of this draft. 172 The SIP User Agent, SIP UA, acts as client and server on behalf of 173 the user. If an IP phone originated the session, the SIP UA resides 174 on the IP phone. If the signal entering the access domain came 175 directly from a gateway, the SIP UA may reside in the access domain, 176 as shown in the figure. In any case, the specific details of this 177 configuration are not relevant to the development in this document. 179 The large box in Figure 1 is labeled as an ISP. In general, it may 180 be an enterprise domain. Additionally, an enterprise domain may 181 outsource SIP services to an ISP. In that case, both domains may be 182 shown in the figure. For simplicity, Figure 1 is shown with a single 183 domain. 185 +-----------------------------------------+ 186 | ISP | 187 | +-----+ +-----+ | 188 | | DIR | | ADB | | 189 | +-----+ +-----+ | 190 | | | | 191 | | | | 192 +-----+ | +-------+ | +----+ 193 |Cstmr| | | |----------------+---| CH | 194 | APS |--+----------------| APS | | +----+ 195 +-----+ | | |------------+ | 196 | +-------+ | | 197 | +--------+ | / | | 198 +-----+ | | SIP UA | | / | | 199 | IP |--+--| | | / | | 200 |Phone| | | +----+ | +----+ / | | Signaling 201 | or | | | |SIP |-+--| SP |--+--------------+---+------------- 202 |Gtwy | | | | | | +----+ / | | 203 +-----+ | | +----+ | / | | 204 | | | / | | 205 | | +----+ | +---+ +----+ | Session data 206 | | | MA |-+--------| R |---------| ER |-+------------- 207 | | +----+ | +---+ +----+ | 208 | +--------+ | 209 +-----------------------------------------+ 211 Figure 1: Components to Support Inter-domain AAA QoS Services 213 The SIP proxy acts as a policy enforcement point, PEP, for IP 214 communication sessions that use SIP. An extension to COPS has been 215 defined that outlines the syntax and semantics of COPS messages and 216 COPS objects for use with SIP [5]. The APS is the corresponding 217 policy decision point, PDP, for SIP sessions. The APS also interacts 218 with the DIR, ADB, customer APS and CH for information on which to 219 base a service usage decision. If QoS is requested and granted, the 220 APS may also interact with applicable network device(s) to aid in 221 QoS setup. 223 Clearinghouses are used to provide scalable, inter-domain AAA 224 services. One or more clearinghouses may be involved in an IP 225 communications session. Network devices along the session data path 226 use one or more QoS mechanisms to provide a user specified level of 227 service. RSVP [6] may be one such QoS mechanism in access networks 228 and Diffserv [7] may be a QoS mechanism in the transit network. 230 Internal routers may or may not participate in bandwidth 231 reservation. If it can be assumed that internal routers are not 232 bottlenecks and will always have sufficient resources to handle 233 requests without reservations, message exchanges with the APS may be 234 eliminated. In this case, the slanted line connecting the APS with R 235 in Figure 1 may be ignored. 237 4. Authorization and Authentication 239 Proper authorization and authentication may be accomplished in a 240 variety of ways. In pursuit of the most suitable technique, various 241 factors must be considered. These factors include: 243 1) minimizing call setup time 244 2) minimizing the time and occurrences that authorization 245 tokens/messages are placed on the wire 246 3) minimizing implementation complexity 247 4) optimization of business relationship models (use of 248 clearinghouses as opposed to many bi-lateral agreements). 250 With these factors in mind, this document discusses some of the 251 requirements of authorization and authentication and suggests one 252 technique as a solution. 254 Requirements of authorization and authentication include: 256 1) user authorization 257 2) inter-domain authorization 259 In this document, user authorization is taken for granted when the 260 session originator is in his/her home domain. This scenario is 261 discussed in the first sub-section below. When the session 262 originator roams into a foreign domain, or another party 263 participating in the session roams into a foreign domain (called 264 party), user authorization is necessary. Foreign domains are 265 referred to as local domains in this document because they are local 266 to the roaming user. This scenario is considered in the second sub- 267 section below. 269 While roaming, user registration is assumed to occur before an IP 270 communication session is initiated [8]. During the user registration 271 process, relevant information is exchanged between the roaming user 272 and the local domain. This information includes the roaming users 273 home domain. The registration process may use the AAA infrastructure 274 described in this document. Further details concerning user 275 registration are out of the scope of this document. 277 The solution suggested within this document to handle AAA 278 requirements in QoS enabled IP communication sessions is with the 279 use of one or more authorization tokens and clearinghouses. This 280 solution makes every attempt to address the factors listed 281 previously to provide the most suitable solution. 283 Although accounting is not discussed in this section, it is an 284 implied necessity. IP communication sessions must trigger the 285 submission of usage indications or reports after session completion. 286 This facilitates correct accounting. 288 4.1. Inter-domain 290 Assume Domain 1, D1, and Domain 2, D2, register with Clearinghouse x 291 (CHx). The necessary security infrastructure is put in place between 292 CHx and D1 and CHx and D2. The security infrastructure must support 293 authentication and authorization services. In some situations it may 294 also be important to support a non-repudiation service to prevent 295 the false denial of IP communication services. 297 Such an infrastructure can be supplied in the form of a public key 298 infrastructure, PKI, based system or a symmetric key based system 299 such as Kerberos. This infrastructure must be operational before the 300 services of CHx are available. If a PKI based system is used D1 may 301 register with CHx, and in the process exchange public key 302 certificates with CHx. CHx may then use the certificate from D1 to 303 authenticate that any message received from D1 actually came from 304 D1. Analogously, D1 may use the certificate from CHx to authenticate 305 that any message received from CHx actually came from CHx. This can 306 be facilitated by the built in security functionality of OSP [9]. 308 Authentication of the SIP proxy and all end users within a domain is 309 the responsibility of the domain administrator. Maintenance of 310 intra-domain security is required because CHx only authenticates D1 311 as a whole through the APS. Intra-domain authentication of users 312 requires another level of authentication not discussed in this 313 section. This level of authentication is an especially important 314 consideration for roaming users. 316 When an end host caller from D1, EH1, calls an end host callee in 317 D2, EH2, the APS in D1, APS1, requests an authorization token from 318 CHx to verify that an appropriate business relationship exists with 319 D2. This development is illustrated in Figure 2. The figure only 320 illustrates messaging that includes the authorization token. 322 If authorization is granted, CHx replies with an authorization token 323 to APS1. This token carries sufficient authentication information so 324 that D2 (and possibly CHx) can later verify that it was created by 325 CHx (or possibly another trusted CH) and not by a fraudulent source. 326 This is in addition to the digital signatures contained in the 327 messages exchanged between CHx and APS1 used to authenticate 328 individual messages. 330 The APS1 may now authorize the call to the SIP proxy of D1, SP1. 331 APS1 may store the session source, destination, and media 332 information to aid in QoS setup. SP1 embeds the authorization token 333 in the SIP INVITE messages and forwards it to the SIP proxy of D2, 334 SP2. 336 Upon reception of the INVITE message, SP2 contacts APS2, passing it 337 the authorization token, to request local and inter-domain 338 authorization to complete session setup. Because the authorization 339 token contains self-authentication information, APS2 can 340 authenticate that CHx has actually authorized the incoming call. 341 This removes the requirement for APS2 to contact CHx. 343 (1) +--------+ 344 +-------| CHx | 345 | +--------+ 346 Domain 1 | Domain 2 347 +----------------+---+ +--------------------+ 348 | | | | | 349 | (2) +------+ | | +------+ (4) | 350 | +----| APS1 | | | | APS2 |----+ | 351 | | +------+ | --------- | +------+ | | 352 | +-----+ (3) | ( Transit ) | +-----+ | 353 | | SP1 +-----------+---( Network )---+---------->+ SP2 | | 354 | +-----+ | ( ) | +-----+ | 355 | +------+ | --------- | +------+ | 356 | | ER1 | | | | ER2 | | 357 | +------+ | | +------+ | 358 | +-----+ | | +-----+ | 359 | | EH1 | | | | EH2 | | 360 | +-----+ | | +-----+ | 361 | | | | 362 +--------------------+ +--------------------+ 364 1) APS1 requests an auth token from CH, triggered by session 365 setup request from EH1 366 2) APS1 returns auth token to SP1 (SP1 embeds token in 367 session signaling message) 368 3) SP1 signals SP2 with embedded token 369 4) SP2 sends auth token to APS2 for authorization and 370 authentication 371 5) auth token no longer used, may be destroyed 373 Figure 2: Authorization Token Life Cycle 375 After EH1 and EH2 have been notified that the IP communication 376 session has been authorized, they may now proceed to reserve 377 bandwidth using a mechanism such as RSVP. Bandwidth management 378 services determine if the requested bandwidth is available over the 379 specified path. 381 The originating and terminating domains have now completed proper 382 inter-domain authorization. If authorization was granted call setup 383 can complete and data may be exchanged over the reserved path. In 384 some models, pre-session establishment of QoS may be a requirement. 385 In such cases, completion of session setup may only transpire if QoS 386 has been established in the required direction(s) [2], [10]. In 387 other models, establishment of QoS and the IP communication session 388 may be decoupled, where each proceeds independently [2]. 390 4.2. Application Level and Pre-call Mobility 392 Mobility of an end user demands additional infrastructure to 393 authenticate and authorize the user while roaming. Three or more 394 domains may be involved in the AAA and call setup process. The local 395 domain may be defined as the domain that the user has roamed into. 396 The home domain may be defined as the domain where the user 397 maintains a user profile that contains, among other things, a list 398 of services for that user. The called domain is the domain in which 399 the called party is present. Note that in the general case, this may 400 not be the called party's home domain. That is, the called party may 401 also be roaming. An additional level of authorization and 402 authentication would be necessary in this case. For simplicity, this 403 document addresses the case where the called party is reached at his 404 or her home domain. 406 In general, authorization and authentication between domains is 407 necessary because billable QoS services may be requested along a 408 path between them. All carriers included in this path who transmit 409 the session data and provide the requested QoS services will expect 410 accounting and/or payment. 412 However, there is a distinction between the end domains where per 413 call accounting may be required and the transit networks that need 414 not to be burdened with the knowledge or understanding of each 415 individual qos flow. For scalability, the transit networks will 416 group all qos flows in some Diffserv class of traffic. The 417 discussion that follows applies only to the end domains where the 418 calls originate and terminate. 420 Accounting agreements can be encompassed in a business relationship 421 with a clearinghouse. An authorization token can be used to verify 422 the business relationship between the local domain and the 423 clearinghouse and the called domain and the clearinghouse. These are 424 the domains between which the session data will travel. 426 A business relationship may also include roaming allowances and 427 services. This implies that a user who roams into a foreign domain 428 may proceed to use the IP communication services that he/she pays 429 for and normally receives from his/her home domain. An authorization 430 token can be used between the local and home domains to verify such 431 a business relationship with a clearinghouse. 433 Under the assumption that the caller pays for services, the local 434 domain is obligated to pay for the bandwidth consumed by the session 435 data between the local and called domains. The charges received by 436 the local domain must propagate back to the home domain of the 437 caller so that the call is ultimately accounted. The charges would 438 likely appear on the caller's monthly statement. The use of 439 authorization tokens to verify business agreements can provide the 440 infrastructure to allow such transactions to be completed. 442 In most cases, SIP signaling sessions which involve mobile SIP 443 terminals will be directed through the home domain of the mobile 444 user in order to maintain home control. Home control is important 445 for the execution of signaled services because the user then sees 446 the same services irrespective of the network capabilities of the 447 local domain he/she has roamed into. These services are contained in 448 a user profile at the user's home domain. 450 The authorization tokens obtained from one or more clearinghouses 451 may be embedded in the SIP signaling during session establishment. 452 The order in which tokens are obtained is not clear at this time. 453 Also, the domain(s) that contact the clearinghouse(s) for 454 authorization token requests is not clear at this time. Two possible 455 scenarios are illustrated in Figures 3 and 4. We note that in each, 456 options exist concerning clearinghouse contacts and messaging order. 458 In Figure 3, session signaling (SIP INVITE message) arrives at the 459 SIP proxy of the local domain (1). The SP, acting as a SIP PEP, 460 makes a request to the APS, acting as a SIP PDP (2). The APS of the 461 local domain contacts one or more clearinghouses seeking appropriate 462 business relationships with the home and called domains (3, 4). If 463 all three domains are registered with the same clearinghouse, only 464 that clearinghouse need be contacted. The clearinghouses return one 465 or more authorization tokens to the APS, which passes them back to 466 the SP. The SP embeds the tokens within the SIP INVITE message and 467 forwards it to the home domain of the caller (5). 469 | Local | Clearing | Home Dom | Called | 470 | Domain | House | of UA1 | Domain | 471 +----------+----------+-----------+----------+ 472 | | | | | 473 | +----+ |3 +----+ | | | 474 | |APS |--+--|CHx | | +-----+ | +----+ | 475 | | | | +----+ | | APS | | |APS | | 476 | | | | | | | | | | | 477 | | | |4 +----+ | | | | | | | 478 | | |--+--|CHy | | +-----+ | +----+ | 479 | +----+ | +----+ | | | | | 480 | | | | | | | | 481 | | | | 6 | | 8 | | 482 | 2 | | | | | | | 483 +---+ | | | | | | | | +---+ 484 |SIP| 1| +----+ | 5 | +-----+ |7 +----+ |9 |SIP| 485 |UA1|--+--| SP |--+----------+--| SP |--+--| SP |--+--|UA2| 486 +---+ | +----+ | | +-----+ | +----+ | +---+ 487 | | | | | 489 Figure 3: Scenario 1 - Session Setup with AAA Support 491 The SP in the home domain contacts the APS using a PEP/PDP 492 relationship (6). The SP or APS refer to the user profile to verify 493 that the requested services allowed. The APS verifies the applicable 494 authorization token and may make additional policy-based admission 495 decisions. The decision is passed back to the SP. The INVITE message 496 is then forwarded to the SP of the called domain (7). The SP 497 contacts the APS using a PEP/PDP relationship (8). The APS verifies 498 the applicable authorization token and may make additional policy- 499 based admission decisions. The decision is passed back to the SP. 500 The SP finally forwards the INVITE message to the called user, SIP 501 UA2 (9). 503 In Figure 4, the messaging is different only in one way. The APS of 504 the local domain contacts the APS of the home domain before any 505 authorization tokens are obtained (3). The APS of the home domain 506 checks the user's profile to authorize the use of services. If the 507 home domain authorizes the session, the APS in the local domain 508 receives a success reply and proceeds to obtain necessary 509 authorization tokens as described for Figure 3. 511 | Local | Clearing | Home Dom | Called | 512 | Domain | House | of UA1 | Domain | 513 +----------+----------+-----------+----------+ 514 | | | | | 515 | +----+ |4 +----+ | | | 516 | |APS |--+--|CHx | | +-----+ | +----+ | 517 | | | | +----+ | | APS | | |APS | | 518 | | | | 3 | | | | | | | 519 | | |--+----------+--| | | | | | 520 | | | | | | | | | | | 521 | | | |5 +----+ | | | | | | | 522 | | |--+--|CHy | | +-----+ | +----+ | 523 | +----+ | +----+ | | | | | 524 | | | | | | | | 525 | | | | 7 | | 9 | | 526 | 2 | | | | | | | 527 +---+ | | | | | | | | +---+ 528 |SIP| 1| +----+ | 6 | +-----+ |8 +----+ |10|SIP| 529 |UA1|--+--| SP |--+----------+--| SP |--+--| SP |--+--|UA2| 530 +---+ | +----+ | | +-----+ | +----+ | +---+ 531 | | | | | 533 Figure 4: Scenario 2 - Session Setup with AAA Support 535 The advantage of the scenario in Figure 4 is that the user's profile 536 is checked before any authorization tokens are obtained. In this 537 way, valuable airtime in the wireless case would not be wasted 538 transporting authorization tokens if the user's profile did not 539 allow the session to proceed. A disadvantage is that call setup time 540 may be lengthened somewhat due to an extra inter-domain message 541 exchange. Another disadvantage may be that a messaging protocol 542 between APSs would have to be defined. COPS is one protocol that may 543 be used for this interaction [11]. 545 The authorization tokens ensure that authentic, billable parties 546 exist and that account, billing and charge settlement may be 547 achieved in a previously agreed upon manner. For scalability, 548 business relationships between domains do not need to exist. 549 Instead, business relationships with a clearinghouse can be used. 551 5. Message Contents 553 This section defines the data content of messages passed between the 554 SIP proxies, APS, and clearinghouse to provide QoS and AAA linkage 555 with SIP for inter-domain IP communication sessions. The messaging 556 discussed does not consider mobility. It considers an originating 557 domain and a terminating domain, each containing a SIP UA, a SIP 558 proxy, and an APS, similar to the illustration in Figure 2. If 559 inter-domain authorization and gateway location services are not 560 required, interaction with a CH and inclusion of an authorization 561 token in all exchanges listed in this section can be ignored. 563 A companion document defines a COPS extension for SIP that details 564 the messaging and message contents between the SP and APS [5]. The 565 current document merely discusses this messaging in general terms. 566 Please refer to the referenced document for full details. 568 5.1. SIP Proxy to APS (Originating Domain) 570 When a SIP proxy receives an INVITE, it sends to the APS source, 571 destination, and possibly media information. The source and 572 destination information may be used by the APS for intra-domain 573 policy-based admission authorization. It must be sent to the CH for 574 inter-domain authorization. 576 The SIP call identifier (callID) can be used by the APS for intra- 577 domain accounting. The callID must be sent to the CH in the 578 authorization request message. The CH may use this identifier when 579 generating an authorization token. 581 If the INVITE contains a SDP attribute specifying bandwidth 582 reservation [10], the APS may need to know the amount of bandwidth 583 requested. The bandwidth is implied by the media description [12], 584 [13]. Bandwidth information is necessary if the APS is charged with 585 the responsibility of managing bandwidth allocation based on user 586 and application information. For example, the APS may have a policy 587 that allows user X to reserve 300 Kbps for multimedia sessions with 588 users A through E and only 50 Kbps multimedia sessions with other 589 users. 591 5.2. APS to CH (from Originating Domain) 593 The information required by the CH for accurate AAA support may be 594 CH dependent. It is expected that all CHs require knowledge of the 595 source and destination domains for basic AAA purposes. The call 596 identifier may be useful for authorization token generation. 597 Bandwidth reservation amount may be required by a CH dependent on 598 the specific business agreement with the domains. This quantity may 599 be used as a basis for granting or denying authorization. If 600 bandwidth reservation amount is required, it must be put into a form 601 agreed upon by the parties involved, such as Kbps. 603 5.3. CH to APS (to Originating Domain) 605 The clearinghouse has the responsibility of making an authorization 606 decision concerning IP communication between the specified source 607 and destination domains. If gateway services are also requested, the 608 decision may also be based upon available gateways and subsequent 609 QoS or cost characteristics corresponding with that gateway. For 610 example, the business relationship of the end domains with the 611 clearinghouse may exclude IP communication sessions that incur costs 612 above a specific limit. Costs may result from long distance charges 613 over the PSTN or from bandwidth reservation over the IP network. The 614 location of a gateway will likely affect one or both of these costs. 616 The CH must return to the APS an authorization decision. If the 617 request is granted, the CH must also return to the APS an 618 authorization token. The authorization token is expected to contain 619 authentication information so that both end point domains recognize 620 it as coming from a trusted CH, as described in a previous section. 621 A transaction identifier may be returned by the CH and subsequently 622 used to correlate original authorization requests with usage 623 indication reports generated after the session has completed. 625 5.4. APS to SIP Proxy (Originating Domain) 627 The APS finally responds to the SIP proxy INVITE message with a 628 status, indicating if the user is allowed to send the INVITE further 629 along the SIP signaling chain. If the authorization is granted, the 630 APS passes the authorization token it received from the CH to the 631 SIP proxy. The SIP proxy includes this token inside the 632 authorization token header field of the INVITE message [14]. 634 5.5. SIP Proxy to SIP Proxy (Originating to Terminating Domain) 636 The SIP proxy forwards the INVITE message containing the 637 authorization token from the originating domain to the terminating 638 domain in the manner defined by SIP. 640 5.6. SIP Proxy to APS (Terminating Domain) 642 The APS in the terminating domain requires the same information as 643 the APS in the originating domain on which to base an intra-domain 644 authorization decision. Additionally, if the APS receives an 645 authorization token, it performs an authentication check on it using 646 the security infrastructure previously established with the CH. This 647 action verifies that the authorization token is authentic and that 648 the requested service has been authorized by a trusted source. 650 6. Protocol Support 651 The exchange of information between the APS and the SIP proxy may be 652 handled using COPS. As mentioned previously, a new COPS extension 653 for SIP is being developed concurrently with this work [5]. 654 Exchanges between the APS and the CH can be handled using OSP [9]. 655 OSP defines all messaging and message data field specifications that 656 are outlined in this document. No additional protocol work is 657 required for this exchange. Also, OSP has been embraced and is in 658 use by a number of large industry participants. 660 7. Messaging Overview 662 This section details the message exchange and message contents to 663 initiate and terminate a SIP-based IP multimedia session. Mobility 664 is not considered in this section. The caller and callee are both 665 present and active at their respective home domains. 667 It is assumed that the media will be transmitted and received from 668 both ends and that bandwidth reservation requests are made in both 669 directions using the SDP attributes discussed in [10]. In the first 670 subsection the inter-domain authorization occurs at the originating 671 domain. In the second subsection the inter-domain authorization 672 occurs at the terminating domain. 673 Descriptions of SIP messages, including requests and responses, are 674 not discussed in this document. They are discussed in detail in [1]. 675 Descriptions of RSVP messages are not discussed in this document but 676 are discussed in detail in [15]. It is assumed that edge routers are 677 RSVP enabled PEPs. Furthermore, it is assumed that the edge routers 678 interact with the APS as PDPs of their respective domains for 679 policy-based management decisions concerning RSVP. Message exchanges 680 of this nature are assumed implicit in this section and are not 681 included in the messaging overview. Details concerning this message 682 exchange are in [16]. 684 As discussed in [2], two QoS models may be defined for IP 685 communication sessions. The QoS assured model is one in which the 686 session and QoS signaling are coupled. In this case the session does 687 not proceed until/unless QoS has been successfully established. The 688 QoS enabled model decouples session and QoS signaling. In this case, 689 the session setup may complete and session data may be exchanged 690 even if QoS has not yet been, or never gets, established. The 691 messaging discussed in this document only considers the QoS enabled 692 model. The development in this section may be extended to work with 693 the QoS enabled model with the inclusion of extra messages defined 694 in [10] and [17]. 696 Since QoS assured is assumed in the session flow examples, the RSVP 697 and SIP messaging are decoupled and may occur asynchronously. The 698 SIP, COPS and OSP messages outlined in the call flow examples may 699 therefore not necessarily be in chronological order with the RSVP 700 messages. 702 All components involved in message passing are illustrated in Figure 703 1. Those in the originating domain are subscripted with "o" and 704 components in the terminating domain are subscripted with "t". The 705 subscript "o/t" implies corresponding components in each domain. The 706 protocol used for each exchange is indicated at each step. Each step 707 also contains notes concerning the contents or special attributes of 708 the message. 710 7.1. Originating Domain Contacts Clearinghouse 712 The following discussion refers to Figures 5 and 6. The step numbers 713 of Figure 5 are indicated as message labels in Figure 6. In step 1, 714 the caller picks up the phone, requests a bandwidth reserved 715 connection and dials a number. This causes the UAo to include 716 appropriate SDP attributes in the SIP INVITE message indicating that 717 QoS is being requested in both directions. The necessary information 718 is passed from the SPo to APSo in step 2. APSo checks if local 719 policy allows the call. This may include interaction with an 720 external policy database, a DIR, an ADB, and/or another APS. 722 If local policy authorizes the call, APSo sends the CH an 723 authorization request for inter-domain authorization in step 3. The 724 CH considers the source and destination information to determine if 725 appropriate business relationships exist with the originating and 726 terminating domains. Bandwidth and/or media information may also be 727 used on which to base a decision. If authorization is granted, the 728 CH generates an authorization token using the call identifier as 729 well as other data. The CH sends the token to the APSo in step 4 730 along with a status value indicating if authorization has been 731 granted or not. The APSo passes this information on to the SPo in 732 step 5. 734 The SPo forwards the INVITE with the embedded authorization token 735 down the SIP signaling chain in step 6 to SPt in the terminating 736 domain. The SPt sends the necessary information to APSt in step 7. 737 The APSt requests local authorization in a similar fashion as that 738 described for the originating domain. The APSt then uses the 739 authorization token and other message data to authenticate the token 740 and determine if inter-domain authorization has been granted. In 741 step 8 the APSt passes a status to the SPt indicating if the session 742 has been authorized. If the call and all requested services are 743 granted, the SPt forwards the INVITE on to the UAt in step 9. 745 The UAt may then send the RSVP Path message to UAo in step 10 since 746 it knows the source and destination addresses and ports and the 747 traffic specifications. Note that in some cases, the SDP sent from 748 UAt to UAo may contain multiple media formats, each having different 749 bandwidth requirements. In this case, the UAo must make a final 750 decision considering the choice of media formats. If the traffic 751 specifications change, additional RSVP messages may be sent to 752 update the network devices along the session data path. 754 In steps 11 and 12 the UAt sends back a 180 (ringing) SIP response 755 to SPo via SPt. In some cases, the UAt may send a 183 (session 756 progress) SIP response followed by a 180 response. The 183 response 757 would follow the same path as the 180 response. For simplicity, only 758 the 180 response is shown in the figures. 760 1) UAo --> SPo (SIP) INVITE; (SDP "a=qos:") 761 2) SPo --> APSo (COPS) src, dest, media, callID 762 3) APSo --> CH (OSP) src, dest, callID 763 4) CH --> APSo (OSP) status, auth token 764 5) APSo --> SPo (COPS) status, auth token 765 6) SPo --> SPt (SIP) INVITE, (SDP "a=qos:"), auth token 766 7) SPt --> APSt (COPS) src, dest, media, callID, auth 767 token 768 8) APSt --> SPt (COPS) status 769 9) SPt --> UAt (SIP) INVITE 770 10) UAt --> R/ERt (RSVP) Path 771 11) UAt --> SPt (SIP) 180 772 12) SPt --> SPo (SIP) 180 773 13) SPo --> APSo (COPS) src, dest, media 774 14) APSo --> SPo (COPS) status 775 15) SPo --> UAo (SIP) 180 776 16) UAo --> R/ERo (RSVP) Path 777 17) UAt --> R/ERt (RSVP) Resv 778 18) UAo --> R/ERo (RSVP) Resv 779 19) UAt --> SPo (SIP) 200 OK via SPt (SDP (a=qos:)) 780 20) SPo --> APSo (COPS) src, dest, media 781 21) APSo --> SPo (COPS) status 782 22) SPo --> UAo (SIP) 200 OK (SDP (a=qos:)) 783 23) UAo --> SPo (SIP) ACK 784 24) SPo --> APSo (COPS) src, dest, media 785 25) APSo --> SPo (COPS) status 786 26) SPo --> SPt (SIP) ACK 787 27) SPt --> APSt (COPS) src, dest, media 788 28) APSt --> SPt (COPS) status 789 29) SPt --> UAt (SIP) ACK 791 30) UAo <-> UAt (RTP) session data exchanged 793 31) UAo --> SPo (SIP) BYE 794 32) SPo --> APSo (COPS) RPT, DRQ 795 33) SPo --> SPt (SIP) BYE 796 34) SPt --> APSt (COPS) RPT, DRQ 797 35) SPt --> UAt (SIP) BYE 798 36) UAo --> ERo (RSVP) PathTear and ResvTear 799 37) UAt --> ERt (RSVP) PathTear and ResvTear 800 38) APSo --> CH (OSP) usage report - session duration, 801 bandwidth consumed, etc. 802 39) APSt --> CH (OSP) usage report - session duration, 803 bandwidth consumed, etc. 805 Figure 5: Message Flow Details 807 The SPo checks if the source, destination or media information are 808 different from what was specified in the INVITE message. If so, SPo 809 sends the information to APSo in step 13. APSo checks local policy 810 and returns a status to SPo in step 14 indicating if the session is 811 still allowed. If so, SPo sends the 180 response to UAo in step 15. 813 +---+ +---+ +----+ +---+ +---+ +---+ +----+ +---+ +---+ 814 |SIP| |SPo| |APSo| |ERo| |CH | |ERt| |APSt| |SPt| |SIP| 815 |UAo| | | | | | | | | | | | | | | |UAt| 816 +---+ +---+ +----+ +---+ +---+ +---+ +----+ +---+ +---+ 817 | | | | | | | | | 818 | 1 | | | | | | | | 819 |------>| 2 | | | | | | | 820 | |----->| 3 | | | | | 821 | | |------------>| | | | | 822 | | | 4 | | | | | 823 | | 5 |<------------| | | | | 824 | |<-----| | | | | | | 825 | | | | 6 | | | | 826 | |---------------------------------------->| | 827 | | | | | | | 7 | | 828 | | | | | | |<-----| | 829 | | | | | | | 8 | | 830 | | | | | | |----->| 9 | 831 | | | | | | | |----->| 832 | | | | | | | 10 | | 833 | | | | | |<-------------------| 834 | | | | | | | | 11 | 835 | | | | 12 | | |<-----| 836 | |<----------------------------------------| | 837 | | 13 | | | | | | | 838 | |----->| | | | | | | 839 | | 14 | | | | | | | 840 | 15 |<-----| | | | | | | 841 |<------| | 16 | | | | | | 842 |-------------------->| | | | 17 | | 843 | | 18 | | | |<-------------------| 844 |-------------------->| | 19 | | | 19 | 845 | |<----------------------------------------|<-----| 846 | | 20 | | | | | | | 847 | |----->| | | | | | | 848 | | 21 | | | | | | | 849 | 22 |<-----| | | | | | | 850 |<------| | | | | | | | 851 | 23 | | | | | | | | 852 |------>| 24 | | | | | | | 853 | |----->| | | | | | | 854 | | 25 | | | | | | | 855 | |<-----| | 26 | | | | 856 | |---------------------------------------->| | 858 Figure 6: Message Flow 860 UAo may now send a RSVP Path message to UAt in step 16 since it 861 knows the source and destination addresses and ports and the traffic 862 specifications. When RSVP Path messages arrive at UAo and UAt, they 863 may send a RSVP Resv message as shown in steps 17 and 18. 865 +---+ +---+ +----+ +---+ +---+ +---+ +----+ +---+ +---+ 866 |SIP| |SPo| |APSo| |ERo| |CH | |ERt| |APSt| |SPt| |SIP| 867 |UAo| | | | | | | | | | | | | | | |UAt| 868 +---+ +---+ +----+ +---+ +---+ +---+ +----+ +---+ +---+ 869 | | | | | | | | | 870 | | | | | | | 27 | | 871 | | | | | | |<-----| | 872 | | | | | | | 28 | | 873 | | | | | | |----->| 29 | 874 | | | | 30 | | |----->| 875 |<------------------------------------------------------>| 876 | 31 | | | | | | | | 877 |------>| 32 | | | | | | | 878 | |----->| | 33 | | | | 879 | |---------------------------------------->| | 880 | | | | | | | 34 | | 881 | | | | | | |<-----| 35 | 882 | | 36 | | | | | |----->| 883 |-------------------->| | | | 37 | | 884 | | | 38 | |<-------------------| 885 | | |------------>| 39 | | | 886 | | | | |<------------| | | 888 Figure 6 (cont'): Message Flow 890 In step 19, UAt sends a final 200 (OK) response to SPo via SPt. If 891 the source, destination or media information are different from what 892 was specified previously, SPo sends a message to APSo in step 20. 893 APSo checks local policy and returns a status to SPo in step 21 894 indicating if the session is still allowed. If so, SPo sends the 200 895 response to UAo in step 22. 897 The UAo confirms reception of the 200 response and establishment of 898 the session by sending a SIP ACK message to SPo in step 23. If the 899 source, destination or media information are different from what was 900 specified previously, SPo sends a message to APSo in step 24. APSo 901 checks local policy and returns a status to SPo in step 25 902 indicating if the session is still allowed. If so, SPo sends the ACK 903 to SPt in step 26. 905 If the source, destination or media information known by SPt are 906 different from what was specified previously, SPt sends a message to 907 APSo in step 27. APSt checks local policy and returns a status to 908 SPt in step 28 indicating if the session is still allowed. If so, 909 SPt sends the ACK to UAt in step 29. 911 The session data is now exchanged via RTP, or some similar protocol, 912 in step 30. The session ends for UAo when the SIP BYE message is 913 sent to SPo in step 31. SPo sends a COPS report and deletes the COPS 914 request state in APSo in step 32. The BYE message is simultaneously 915 forwarded to SPt in step 33. SPt sends a COPS report and deletes the 916 COPS request state in APSt in step 34. The BYE message is sent to 917 UAt in step 35. 919 PathTear and ResvTear messages are sent from UAo and UAt upon call 920 completion (from UAt when it receives the BYE message) in steps 36 921 and 37. This triggers a COPS DRQ from ERo and ERt to APSo and APSt, 922 respectively. These messages are not shown but implicitly implied. 923 APSo and APSt may then perform necessary accounting/bookkeeping 924 chores. Alternately, ResvErr messages may be sent by an APS under 925 cancellation circumstances by APSo or APSt. 927 The APSo and APSt send usage reports to the CH in steps 38 and 39 to 928 indicate session duration, QoS services consumed such as bandwidth, 929 and possibly other session details necessary for inter-domain 930 accounting and settlement. 932 Usage indication reports are sent to the CH in steps 30 and 31. 933 Depending on the business agreement and the services used, this 934 interaction may require contact between the SPo/t and the APSo/t. 936 Other circumstances may cause the reservation in one or both 937 directions to fail. In this case, ResvErr messages may be injected 938 into the session data path. Upon reception of a PathErr or ResvErr 939 message, an ERo/t would remove the corresponding state and notify 940 APSo/t. 942 7.2. Terminating Domain Contacts Clearinghouse 944 The caller may have a reason to allow the terminating domain to 945 contact the CH for inter-domain authorization. For example, the 946 caller may require that the callee make an unusually large bandwidth 947 reservation for a critical IP communication exchange. The caller 948 does not know the limits of services the callee is entitled to. In 949 this case the caller may forego inter-domain authorization during 950 call setup. Instead, the APSt, on behalf of the callee, receives the 951 INVITE without a token, negotiates for an allowable level of 952 service, then contacts the CH for an authorization request. The 953 resulting authorization token is then placed inside the 200 response 954 sent back to the caller. Such a scenario may only make sense if the 955 CH requires bandwidth information (or other QOS service information 956 such as latency or jitter) to make an authorization decision. 958 The benefits of this are debatable. One advantage is that if 959 successful negotiation is not possible, the call may be cancelled 960 without contacting the CH, saving a message exchange. The message 961 exchange scenario is similar to that of Figure 5 with minor changes. 963 8. Accounting, Charging and Billing 965 We make a clear distinction between accounting, charging and billing 966 and provide a summary, possibly incomplete description. 968 Accounting: The process of logging the usage of network resources, 969 such as QoS or PSTN gateway service. The accounting data may or may 970 not be used for usage charging, depending on the service model. This 971 draft addresses accounting only and does not address charging and 972 billing. 974 Charging: Allocating the cost to various parties according to some 975 business policies. Cost allocation may depend on such parameters as 976 class of service, geographic locations, time of day, promotions, 977 incentives for resellers and other. Examples of different business 978 policies and classes of service are usage based charging and flat 979 rate subscription rates. 981 Billing: Informing various users of the charges and expected 982 payments. 984 9. Security Considerations 986 This document addresses some security issues concerning 987 authentication of inter-domain business relationships. The protocols 988 discussed in this work, SIP, COPS and OSP contain their own security 989 mechanisms. Any security issues not addressed by SIP, COPS or OSP 990 have not been considered in this work and are left as open issues. 992 10. Acknowledgments 994 The authors would like to thank Russ Fenger, Arun Raghunath, 995 Changwen Liu, Mark Grosen, Jeff Mark, Kalon Kelley and Dave Durham 996 for insightful discussions and valuable contributions. 998 11. References 1000 [1] Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., 1001 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 1003 [2] Sinnreich, H., Donovan, S., Rawlins, D., Thomas, S., 1004 "Interdomain IP Communications with QoS, Authorization and Usage 1005 Reporting", Internet Draft, Internet Engineering Task Force, 1006 February 2000, Work in progress. 1008 [3] Sinnreich, H., Rawlins, D., Johnston, A., Donovan, S., Thomas, 1009 S., "AAA Usage for IP Telephony with QoS", Internet Draft, Internet 1010 Engineering Task Force, July 2000, Work in progress. 1012 [4] Bradner, S., "Key words for use in RFCs to indicate requirement 1013 levels", RFC 2119, March 1997. 1015 [5] Gross, G., Sinnreich, H., Rawlins, D., Thomas, S., "COPS Usage 1016 for SIP", Internet Draft, Internet Engineering Task Force, November 1017 2000, Work in progress. 1019 [6] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 1020 "Resource ReSerVation Protocol (RSVP) � Functional Specification", 1021 RFC 2205, September 1997. 1023 [7] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, 1024 W., "An Architecture for Differentiated Services", RFC 2475, 1025 December 1998. 1027 [8] Schulzrinne, H., "SIP Registration", Internet Draft, Internet 1028 Engineering Task Force, October 2000, Work in progress. 1030 [9] European Telecommunications Standards Institute. 1031 "Telecommunications and Internet Protocol Harmonization Over 1032 Networks (TIPHON); Inter-domain pricing, authorization, and usage 1033 exchange". Technical Specification 101 321 version 1.4.2, December 1034 1998. 1036 [10] Marshall, W., et al. "Integration of Resource Management and 1037 SIP", Internet Draft, Internet Engineering Task Force, June 2000, 1038 Work in progress. 1040 [11] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R. and A. 1041 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, 1042 January 2000. 1044 [12] Handley, M. and Jacobson, V., "SDP: Session Description 1045 Protocol", RFC 2327, April 1998. 1047 [13] Schulzrinne, H., "RTP Profile for Audio and Video Conferences 1048 with Minimal Control", RFC 1890, January 1996. 1050 [14] Johnston, A., Rawlins, D., Sinnreich, H., Thomas, S., "OSP 1051 Authorization Token Header for SIP", Internet Draft, Internet 1052 Engineering Task Force, November 2000, Work in progress. 1054 [15] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 1055 "Resource ReSerVation Protocol (RSVP) � Functional Specification", 1056 RFC 2205, September 1997. 1058 [16] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 1059 Sastry, A., "COPS Usage for RSVP", RFC 2749, January 2000. 1061 [17] Rosenberg, J. and Schulzrinne, H., "Reliability of Provisional 1062 Responses in SIP", Internet Draft, Internet Engineering Task Force, 1063 June 2000, Work in progress. 1065 12. Author's Address 1067 Gerhard Gross 1068 Intel Corporation 1069 MS JF3-206 1070 2111 NE 25th Ave. 1071 Hillsboro, OR 97124 1072 Phone: +1-503-264-6389 1073 Fax: +1-503-264-3483 1074 gerhard.gross@intel.com 1076 Diana Rawlins 1077 WorldCom 1078 901 International Parkway 1079 Richardson, Texas 75081 1080 USA 1081 diana.rawlins@wcom.com 1083 Henry Sinnreich 1084 WorldCom 1085 400 International Parkway 1086 Richardson, Texas 75081 1087 USA 1088 henry.sinnreich@wcom.com 1090 Stephen Thomas 1091 TransNexus, LLC 1092 430 Tenth Street NW 1093 Suite N-204 1094 Atlanta, GA 30318 1095 USA 1096 stephen.thomas@transnexus.com 1098 13. Full Copyright Statement 1100 Copyright (C) The Internet Society (1999). All Rights Reserved. 1102 This document and translations of it maybe copied and furnished to 1103 others, and derivative works that comment on or otherwise explain it 1104 or assist in its implementation may be prepared, copied, published 1105 and distributed, in whole or in part, without restriction of any 1106 kind, provided that the above copyright notice and this paragraph 1107 are included on all such copies and derivative works. However, this 1108 document itself may not be modified in any way, such as by removing 1109 the copyright notice or references to the Internet Society or other 1110 Internet organizations, except as needed for the purpose of 1111 developing Internet standards in which case the procedures for 1112 copyrights defined in the Internet Standards process must be 1113 followed, or as required to translate it into languages other then 1114 English. 1116 The limited permissions granted above are perpetual and will not be 1117 revoked by the Internet Society or its successors or assigns. 1119 This document and the information contained herein is provided on an 1120 "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING 1121 TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1122 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON 1123 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF 1124 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.