idnits 2.17.1 draft-ietf-speermint-voip-consolidated-usecases-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1120. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1133. 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 323 has weird spacing: '...service regx...' == Line 331 has weird spacing: '...riority weigh...' == Line 652 has weird spacing: '...service reg...' == Line 660 has weird spacing: '...riority weigh...' == 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.) -- The document date (May 29, 2008) is 5808 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4366 (Obsoleted by RFC 5246, RFC 6066) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMING Working Group A. Uzelac, Ed. 3 Internet-Draft Global Crossing 4 Intended status: Informational Y. Lee, Ed. 5 Expires: November 30, 2008 Comcast Cable 6 May 29, 2008 8 VoIP SIP Peering Use Cases 9 draft-ietf-speermint-voip-consolidated-usecases-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 30, 2008. 36 Abstract 38 This document depicts many common VoIP use case for SIP Peering. 39 These use cases are categorized into static and on-demand, and then 40 further sub-categorized into direct and indirect. These use cases 41 are not an exhaustive set, but rather the most common use cases 42 deployed today. This document captures them to provide a reference. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Reference Architecture . . . . . . . . . . . . . . . . . . . . 3 52 4. Contexts of Use Cases . . . . . . . . . . . . . . . . . . . . 4 54 5. User Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5.1. Static Peering Use Cases . . . . . . . . . . . . . . . . . 6 56 5.1.1. Static Direct Peering Use Case . . . . . . . . . . . . 6 57 5.1.2. Static Direct Peering Use Case - Assisted LUF and 58 LRF . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 5.1.3. Static Indirect Peering Use Case - Assisted LUF 60 and LRF . . . . . . . . . . . . . . . . . . . . . . . 13 61 5.1.4. Static Indirect Peering Use Case . . . . . . . . . . . 18 63 6. On-demand Peering Use Cases . . . . . . . . . . . . . . . . . 20 64 6.1. On-demand Direct Peering Use Case . . . . . . . . . . . . 20 65 6.1.1. Administrative characteristics . . . . . . . . . . . . 20 66 6.1.2. Options and Nuances . . . . . . . . . . . . . . . . . 20 68 7. Federations . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 7.1. Federation Examples . . . . . . . . . . . . . . . . . . . 21 70 7.1.1. Trivial Federations . . . . . . . . . . . . . . . . . 21 71 7.1.2. Access List based Federations . . . . . . . . . . . . 21 72 7.1.3. Central SIP Proxy Federations . . . . . . . . . . . . 22 73 7.1.4. Architecture, scalability and business scalability . . 22 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 86 Intellectual Property and Copyright Statements . . . . . . . . . . 26 88 1. Introduction 90 This document attempts to capture VoIP use cases for Session 91 Initiation Protocol (SIP) [RFC3261] based peering. These use cases 92 will assist in identifying requirements and future works for VoIP 93 Peering using SIP. 95 Only use cases related to VoIP are considered in this document. 96 Other real-time SIP communications use cases, like Instant Messaging 97 (IM) and presence are out of scope for this document. In describing 98 use cases, the intent is descriptive, not prescriptive. 100 There are existing documents [I-D.lee-speermint-use-case-cable], 101 [I-D.lendl-speermint-federations], 102 [I-D.mahy-speermint-direct-peering], 103 [I-D.schwartz-speermint-use-cases-federations], and 104 [I-D.uzelac-speermint-use-cases] that have captured use case 105 scenarios. This draft draws from those documents. The use cases 106 contained in this document attempts to be as comprehensive as 107 possible, but should not be considered the exclusive set of use 108 cases. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Reference Architecture 118 The diagram below provides the reader with a context for the VoIP use 119 cases in this draft. 121 +-------------------+-------------------------+-------------------+ 122 | | LUF/LRF Provider Domain | | 123 | | Indirect SSP Domain | | 124 | | | | 125 | | +------+ +------+ | | 126 | | +A-LUF + + A-LRF| | | 127 | | +------+ +------+ | | 128 | | | | 129 | | +------+ +------+ | | 130 | | | I-SBE| | I-DBE| | | 131 | \ +------+ +------+ / | 132 | +------+ \ / +------+ | 133 | +-----+O-LUF | \ / |T-LUF +-----+ | 134 | | +O-LRF | \ / |T-LRF + | | 135 | | +------+ \ / +------+ | | 136 | | \ / | | 137 | | +------+ \ / +------+ | | 138 | | | O-SBE| \ / | T-SBE| | | 139 | | +---+--+ \ / +---+--+ | | 140 | | | \ / | | | 141 | | | \ / | | | 142 | | +---+---+ \ / +---+---+ | | 143 | +-----+O-Proxy| \ / |T-Proxy+--- + | 144 | +-----+-+ + +-+-----+ | 145 | +----+ | | | +----+ | 146 | |UAC +--------+ | +--------+ UAS| | 147 | +----+ +------+ | +------+ +----+ | 148 | | O-DBE| | | T-DBE| | 149 | +------+ | +------+ | 150 | | | 151 | Originating SSP Domain | Terminating SSP Domain | 152 +-----------------------------------------------------------------+ 154 General Overview 156 Figure 1 158 PLEASE NOTE: In Figure 1 - the elements defined are optional in many 159 use cases. 161 4. Contexts of Use Cases 163 Use cases are sorted into two general groups: Static and On-demand 164 Peering [I-D.ietf-speermint-terminology]. Each group can be further 165 sub-divided to Direct Peering and Indirect Peering 166 [I-D.ietf-speermint-terminology]. Though there may be some overlap 167 among the use cases in these categories, there are different 168 requirements between the scenarios. Each use-case must specify a 169 basic set of required operations to be performed by each member when 170 peering. 172 These can include: 174 o Peer Discovery - Peer discovery via a Look-Up Function (LUF) to 175 determine the administrative domain of the target. 177 o Location Determination - A location determination process serves 178 to create the Session Establishment Data (SED). Examples: Public 179 User-ENUM, public Infrastructure ENUM, private ENUM tree, SIP 180 Redirect, DUNDi. 182 o Next Hop Determination - A next hop determination based on the SED 183 is then completed. If Location Routing Function (LRF) query did 184 not return an URI of the form sip:user@IP-address, then the 185 originating SSP has to translate the domain part of the URI to an 186 IP-address (plus perhaps fall-backs) in order to contact the next 187 hop. Examples: [RFC3263] in the public DNS. [RFC3263] in a 188 federation private DNS. [RFC3263] in the public DNS with split- 189 DNS, P2P SIP, modified [RFC3263] in the public DNS (e.g. a 190 federation-specific prefix to the domain name). 192 o Call setup - SSPs that are interconnecting to one another may also 193 define specifics on what SIP features need to be used when 194 contacting the next hop in order to a) reach the next hop at all 195 and b) to prove that the sender is a legitimate peering partner. 197 Examples: hard-code transport (TCP/UDP/TLS), non-standard port 198 number, specific source IP address (e.g. in a private L3 network), 199 which TLS client certificate [RFC4366] to use, and other 200 authentication schemes. 202 o Call reception - This step serves to ensure that the type of 203 relationship (static or on-demand, indirect or direct) is 204 understood and acceptable. For instance, the receiving side 205 border elements need to determine whether the INVITE it just 206 received really came from a member of the federation, possibly via 207 an access control list entry. This is the flip side of step four. 208 Example: verify TLS certificate [RFC4366] check incoming 209 interface/VLAN,check source IP address against a configured list 210 of valid ones. 212 5. User Cases 214 Please note there are intra-domain message flows within the use cases 215 to serve as supporting background information. Only inter-domain 216 communications are germane to Speermint. 218 5.1. Static Peering Use Cases 220 Static Peering [I-D.ietf-speermint-terminology] describes the use 221 case when two SSPs form a peering relationship with some form of 222 association established prior to the exchange of traffic. Pre- 223 association is a prerequisite to static peering. Static peering is 224 used in cases when two peers want a consistent and tightly controlled 225 approach to peering. In this scenario, a number of variables, such 226 as remote proxy IP address and QoS parameters, can be defined upfront 227 and known by each SSP prior to peering. 229 5.1.1. Static Direct Peering Use Case 231 This is the simplest form of a peering use case. Two SSPs negotiate 232 and agree to establish a SIP peering relationship. The peer 233 connection is statically configured and is direct between the 234 connected SSPs. The peers may exchange interconnection parameters 235 such as DSCP policies, subscriber SIP-URI and proxy location prior to 236 establishing the interconnection. Typically, they only accept 237 traffic originating directly from the trusted peer. 239 +--------------------+ +---------------------+ 240 | O-SSP | | T-SSP | 241 | +-----+ | | +-----+ | 242 | |O-LUF| | | |T-LUF| | 243 | |O-LRF| | | /|T-LRF| | 244 | /+-----+\ | | / +-----+ | 245 | (2) (4,5,6) | | / | 246 | / \ | | /(8,9) | 247 |+-------+ +-----+ +-----+ +-------+| 248 ||O-Proxy|-(3)-|O-SBE+-----(7)-----+T-SBE|-(10)-|T-Proxy|| 249 |+-------+ +-----+ +-----+ +-------+| 250 | | | | | | 251 | (1) | | (11) | 252 | | | | | | 253 | +-----+ | | +-----+ | 254 | | UAC +============+=====(12)====+=============+ UAS | | 255 | +-----+ | | +-----+ | 256 +--------------------+ +---------------------+ 257 example.com example.net 259 Static Direct Peering Use Case 261 Figure 2 263 The following is a high-level depiction of the use case: 265 1. UAC initiates a call via SIP INVITE to O-Proxy. O-Proxy is the 266 home proxy for UAC. 268 INVITE sip:+19172223333@example.com;user=phone SIP/2.0 269 Via: SIP/2.0/TCP client.example.com:5060 270 ;branch=z9hG4bK74bf9 271 Max-Forwards: 10 272 From: Alice 273 ;tag=12345 274 To: Bob 275 Call-ID: abcde@client.example.com 276 CSeq: 1 INVITE 277 Contact: 280 2. Note that UAC only knows UAS's TN but not UAS's domain. It 281 appends its own domain to generate the SIP-URI in R-URI and To 282 header. O-Proxy checks the R-URI's domain and discovers that 283 the UAS's domain is internal but the TN is unknown to O-Proxy. 284 So, O-Proxy queries LUF for SED information from a routing 285 database. In this example, the LUF is an ENUM database. The 286 ENUM entry looks similar to this: 288 $ORIGIN 3.3.3.3.2.2.2.7.1.9.1.example.com 289 NAPTR 10 100 "u" "E2U+SIP" 290 "!^.*!sip:\1@t-sbe.example.net!" 292 This SED data can be inputted by O-SSP or populated by the 293 T-SSP. 295 3. O-Proxy examines the SED and discover the domain is external. 296 Given the O-Proxy's internal routing policy, O-Proxy decides to 297 use O-SBE to reach T-SBE, so it routes the INVITE request to 298 O-SBE. O-SBE rewrites the R-URI with the SED and adds a Route 299 header which contains O-SBE. 301 INVITE sip:+19172223333@t-sbe.example.net;user=phone SIP/2.0 302 Via: SIP/2.0/TCP o-proxy.example.com:5060 303 ;branch=z9hG4bKye8ad 304 Via: SIP/2.0/TCP client.example.com:5060 305 ;branch=z9hG4bK74bf9;received=192.0.2.1 306 Max-Forwards: 9 307 Route: 308 Record-Route: 309 From: Alice 310 ;tag=12345 311 To: Bob 312 Call-ID: abcde@client.example.com 313 CSeq: 1 INVITE 314 Contact: 317 4. O-SBE receives the requests and pops the top entry of the Route 318 header which contains "o-sbe1.exapmle.com". O-SBE examines the 319 R-URI and does a LRF for "t-sbe.example.net". In this example, 320 the LRF is a DNS lookup of the domain name. O-SBE receives a 321 NAPTR response form LRF. The response looks similar to this: 323 ;; order perf flags service regxp replacement 324 IN NAPTR 50 50 "S" "SIP+D2T" "" _sip._tcp.t-sbe.example.net 325 IN NAPTR 90 50 "S" "SIP+D2U" "" _sip._udp.t-sbe.example.net 327 5. Given the lower order for TCP in the NAPTR response, O-SBE 328 decides to use TCP for transport protocol, so it sends a DNS 329 query for the SRV record for "_sip._tcp.t-sbe.example.net". 331 ;; priority weight port target 332 IN SRV 0 1 5060 t-sbe1.example.net 333 IN SRV 0 2 5060 t-sbe2.example.net 335 6. O-SBE sends a DNS query for "t-sbe1.example.net" to get the 336 A-Record: 338 ;; DNS ANSWER 339 t-sbe1.example.net A 192.0.2.10 340 t-sbe1.example.net A 192.0.2.11 342 7. O-SBE sends the INVITE to T-SBE. O-SBE is the entry point to 343 the O-SSP domain, so it should ensure subsequent mid-dialog 344 requests traverse via itself. If O-SBE chooses to act as B2BUA 345 , it will terminate the call and generate a new back-to-back 346 INVITE request. If O-SBC chooses to act as proxy, it should 347 record-route to stay in the call path. In this example, O-SBE 348 is a B2BUA. 350 INVITE sip:+19172223333@t-sbe1.example.net;user=phone SIP/2.0 351 Via: SIP/2.0/TCP o-sbe1.example.com:5060 352 ;branch= z9hG4bK2d4zzz; 353 Max-Forwards: 10 354 From: Alice 355 ;tag=54321 356 To: Bob 357 Call-ID: abcde-osbe1@o-sbe1.example.com 358 CSeq: 1 INVITE 359 Contact: 362 Note that O-SEB may re-write the R-URI with the target domain in 363 the SIP-URI. Some proxy implementation will only accept the 364 request if the R-URI contains its own domain. 366 8. T-SBE determines called party home proxy and directs call to 367 called party. T-SBE may use ENUM or other internal mechanism to 368 locate the home proxy. If T-SSP uses ENUM, this internal ENUM 369 entry is different from the external ENUM entry populated for 370 O-SSP. For internal use, it should return the home proxy of 371 UAS. For external use, it should return T-SBE. 373 $ORIGIN 3.3.3.3.2.2.2.7.1.9.1.example.net 374 NATPTR 10 100 "u" "E2U+SIP" 375 "!^.*!sip:+19172223333@t-proxy.example.net!" 377 9. T-SBE receives the NAPTR record and query DNS for the 378 "t-proxy.example.net". The DNS returns an A-Record: 380 ;; DNS ANSWER 381 t-proxy.example.net A 192.0.2.20 383 10. T-SBE is a B2BUA, so it generates a new INVITE and sends it to 384 UAS's home proxy: 386 INVITE sip:+19172223333@t-proxy.example.net;user=phone SIP/2.0 387 Via: SIP/2.0/TCP t-sbe1.example.net:5060 388 ;branch= z9hG4bK28uyyy; 389 Max-Forwards: 10 390 From: Alice 391 ;tag=54321 392 To: Bob 393 Call-ID: abcde-tsbe1@t-sbe1.example.com 394 CSeq: 1 INVITE 395 Contact: 398 11. Finally, UAS's home proxy forwards the INVITE request to UAS. 400 INVITE sip:+19172223333@server.example.net;user=phone SIP/2.0 401 Via: SIP/2.0/TCP t-proxy.example.net:5060 402 ;branch= z9hG4bK28u111; 403 Via: SIP/2.0/TCP t-sbe1.example.net:5060 404 ;branch= z9hG4bK28uyyy; received=192.0.2.20 405 Max-Forwards: 9 406 Record-Route: , 407 408 From: Alice 409 ;tag=54321 410 To: Bob 411 Call-ID: abcde-tsbe1@t-sbe1.example.com 412 CSeq: 1 INVITE 413 Contact: 416 12. RTP is established between UAC and UAS. 418 5.1.1.1. Administrative characteristics 420 The static direct peering use case is typically implemented in a 421 scenario where exists a strong degree of trust between the two 422 administrative domains. Both administrative domains typically sign a 423 peer agreement which state clearly the peering policies and terms. 425 5.1.1.2. Options and Nuances 427 In Figure 2. O-SSP and T-SSP peer via SBEs. Normally, the operator 428 will deploy the SBE in the edge of its administrative domain. The 429 signalling traffic will pass between two networks through the SBEs. 430 The operator has many reasons to deploy a SBE. For example, either 431 proxy and UA may use [RFC1918] addresses that are not routable in the 432 target network. The SBE can perform a NAT function. Also, the SBE 433 eases the operation cost for deploying or removing L5 network 434 elements. Consider the deployment architecture where multiple 435 proxies connect to a single SBE. An operator can add or remove a 436 proxy without coordinating with the peer operator. The peer operator 437 "sees" only the SBE. As long as the SBE is maintained in the path, 438 the peer operator does not need to be notified. 440 When an operator deploys a SBE, the operator is required to advertise 441 the SBE to the peer LRF so that the peer operator can locate the SBE 442 and route the traffic to the SBE accordingly. 444 SBE deployment is a decision within an administrative domain. Either 445 administrative domain or both administrative domains can decide to 446 deploy SBE. To the peer network, most important is to identify the 447 next-hop address. Whether next-hop is a proxy or SBE, the peer 448 network will not see any difference. 450 5.1.2. Static Direct Peering Use Case - Assisted LUF and LRF 452 This use case shares many properties with the static direct use case. 453 There must exist a pre-association between the O-SSP and T-SSP. The 454 difference is O-SSP will use the Assisted LUF/LRF Provider for LUF 455 and LRF. This LUF/LRF provider stores the SED pre-populated by 456 T-SSP. One important motivation to use the Assisted LUR/LRF provider 457 is that T-SSP only needs to populate its SED once to the provider. 458 Any O-SSP who wants to query T-SSP's SED can use this LUF/LRF 459 provider. Current practice has shown that it is impractical for 460 T-SSP to populate its SED to every O-SSP who likes to reach the 461 T-SSP's subscribers. This is especially true in Enterprise 462 environments. 464 +-----------------+ 465 |LUF/LRF Provider | 466 | | 467 | +-------+ | 468 | +-+ A-LUF | | 469 | / | A-LRF | | 470 +--------------------+ / ++-------+ +---------------------+ 471 | O-SSP |/ / | T-SSP | 472 | +------------/ (4,5,6) | +-----+ | 473 | / | / | |T-LUF| | 474 | (2) +--+ | +-|T-LRF| | 475 | / / | | / +-----+ | 476 | / / | | /(8,9) | 477 |+-------+ +-----+ +-----+ +-------+| 478 ||O-Proxy|-(3)-|O-SBE+-------(7)-------+T-SBE|-(10)-|T-Proxy|| 479 |+-------+ +-----+ +-----+ +-------+| 480 | | | | | | 481 | (1) | | (11) | 482 | | | | | | 483 | +-----+ +-----+ +-----+ +-----+ | 484 | | UAC +======|0-DBE+=======(12)======+T-DBE+=======+ UAS | | 485 | +-----+ +-----+ +-----+ +-----+ | 486 +--------------------+ +---------------------+ 487 example.com example.net 489 Static Direct Peering with Assisted LUF and LRF 491 Figure 3 493 The call flow looks almost identical to Static Direct Peering Use 494 Case except Step 2,4,5 and 6 which happen in the Assisted LUF/LRF 495 provider remotely instead of happening in O-SSP domain. 497 Note that the media passes through O-DBE and T-DBE in the Figure 3. 498 This is optional. A DBE may be needed for transcoding or other 499 traffic policy for media. 501 5.1.2.1. Administrative Characteristics 503 The Assisted LUF/LRF provider provides the LUF and LRF services for 504 the O-SSP. As such , LUF/LRF providers, O-SSP and T-SSP form a 505 trusted administrative domain. To reach T-SSP, O-SSP must still 506 require pre-arranged assignments for the peer relationship with 507 T-SSP. L5 policy is maintained in the O-SSP and T-SSP domains, and 508 LUF/LRF provider may not aware any L5 policy between O-SSP and T-SSP. 510 An Assisted LUF/LRF provider can serve multiple administrative 511 domains. the Assisted LUF/LRF provider must not share SED from one 512 administrative domain to another administrative domain without 513 appropriate permission granted. 515 5.1.2.2. Options and Nuances 517 The Assisted LRF/LRF provider can use multiple methods to provide SED 518 to O-SSP. Most commonly used are ENUM query and SIP Redirect. O-SSP 519 should negotiate with the Assisted LUF/LRF provider which query 520 method it will use prior to sending query to the provider. 522 T-SSP needs to populate its users' SED to LUF/LRF provider. 523 Currently, this procedure is non-standardized and labor intensive. 524 IETF is working on this problem and trying to standardize this 525 procedure for ENUM. [I-D.newton-peppermint-problem-statement], 526 [I-D.lewis-peppermint-enum-reg-if], and 527 [I-D.schwartz-peppermint-problem-statement] list the problem 528 statements and requirements. 530 5.1.3. Static Indirect Peering Use Case - Assisted LUF and LRF 532 The difference between Static Direct Use Case and Static Indirect Use 533 Case lies with the Layer-5 relationship O-SSP and T-SSP maintain. In 534 the Indirect use case, the O-SSP and T-SSP do not have direct Layer-5 535 connectivity. They require one or multiple Indirect Domains to 536 assist routing the SIP messages and possibly the associated media. 538 In this use case, O-SSP and T-SSP want to form peer relationship. 539 For some reason, O-SSP and T-SSP don't have direct L5 connectivity. 540 The reasons may vary, for example business demands and/or domain 541 policy controls. Due to this indirect relationship the signalling 542 will traverse from O-SSP to one or multiple I-SSP(s) to reach T-SSP. 544 In Enterprise environments, O-SSP normally forms peer relationship 545 with an I-SSP or two I-SSP for redundancy. To reach T-SSP, O-SSP 546 will forward the request to I-SSP and rely on I-SSP to route the 547 request to T-SSP. This setup alleviates the requirements to 548 establish direct peer relationship to every T-SSP. Thus, reduces the 549 administration cost to manage a large number of peer relationships. 551 To further reduce the administration cost, O-SSP in this use case use 552 an Assisted LUF/LRF provider to manage LUF/LRF. 554 Note that the Assisted LUF/LRF provider and I-SSP can be the same 555 provider or different providers. 557 +------------------+ 558 | LUF/LRF Provider | 559 | I-SSP | 560 | +-------+ | 561 | ---+ A-LUF | | 562 | / | A-LRF | | 563 +--------------------+ / +-------+ +---------------------+ 564 | O-SSP |/ / | T-SSP | 565 | +-------------/ / | +-----+ | 566 | / |(4,5,6) | |T-LUF| | 567 | / | / | +----+T-LRF| | 568 | (2) + +--- | / +-----+ | 569 | / / | | /(9,10) | 570 |+-------+ +-----+ +-----+ +-----+ +-------+| 571 ||O-Proxy|-(3)-|O-SBE+-(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy|| 572 |+-------+ +-----+ +-----+ +-----+ +-------+| 573 | | | | | | 574 | (1) | | (12) | 575 | | | | | | 576 | +-----+ +-----+ +-----+ +-----+ +-----+ | 577 | | UAC +=(13)=|0-DBE+=====+I-DBE+======+T-DBE+=======+ UAS | | 578 | +-----+ +-----+ +-----+ +-----+ +-----+ | 579 +-------------------------------------------------------------+ 580 example.com example.org example.net 582 Indirect Peering via LUR/LRF provider and I-SSP (SIP and media) 584 Figure 4 586 The following is a high-level depiction of the use case: 588 1. UAC initiates a call via SIP INVITE to O-Proxy. O-Proxy is the 589 home proxy for UAC. 591 INVITE sip:+19172223333@example.com;user=phone SIP/2.0 592 Via: SIP/2.0/TCP client.example.com:5060 593 ;branch=z9hG4bK74bf9 594 Max-Forwards: 10 595 From: Alice 596 ;tag=12345 597 To: Bob 598 Call-ID: abcde@client.example.com 599 CSeq: 1 INVITE 600 Contact: 603 2. UAC only knows UAS's TN but not UAS's domain. It appends its 604 domain to generate the SIP-URI in R-URI and To header. O-Proxy 605 checks the R-URI's domain and discovers that the UAS's domain is 606 internal but the TN is unknown to O-Proxy. So, O-Proxy queries 607 LUF for SED information from a routing database. In this 608 example, the LUF is an ENUM database. The ENUM entry looks 609 similar to this: 611 $ORIGIN 3.3.3.3.2.2.2.7.1.9.1.example.com 612 NATPTR 10 100 "u" "E2U+SIP" 613 "!^.* !sip:\\1@i-sbe.example.org!" 614 Note that the response shows the next-hop is the SBE in Indirect 615 SSP. 617 Alternatively, O-SSP may have a pre-association with I-SSP. As 618 such, O-SSP will forward all requests of which it contains an 619 external domain or the TN is unknown to O-SSP to I-SSP. O-SSP 620 will rely on I-SSP to determine T-SSP and route the request 621 correctly. In this setup, O-SSP can skip Steps 2,4,5 and 6 and 622 forward the request to I-SBE. This setup is commonly used in 623 Enterprise use cases. 625 3. Given the O-Proxy's internal routing policy, O-Proxy decides to 626 use O-SBE to reach I-SBE, so it routes the INVITE request to 627 O-SBE rewrites the R-RUI with the SED and adds a Route header 628 which contains O-SBE. 630 INVITE sip:+19172223333@i-sbe.example.org;user=phone SIP/2.0 631 Via: SIP/2.0/TCP o-proxy.example.com:5060 632 ;branch=z9hG4bKye8ad 633 Via: SIP/2.0/TCP client.example.com:5060 634 ;branch=z9hG4bK74bf9;received=192.0.2.1 635 Max-Forwards: 9 636 Route: 637 Record-Route: 638 From: Alice 639 ;tag=12345 640 To: Bob 641 Call-ID: abcde@client.example.com 642 CSeq: 1 INVITE 643 Contact: 646 4. O-SBE receives the requests and pops the top entry of the Route 647 header which contains "o-sbe1.example.com". O-SBE examines the 648 R-URI and does a LRF for "i-sbe.example.org". In this example, 649 the LRF is a DNS lookup of the domain. O-SBE receives a 650 response similar to this: 652 ;; order perf flags service regxp replacement 653 IN NAPTR 50 50 "S" "SIP+D2T" "" _sip._tcp.i-sbe.example.org 654 IN NAPTR 90 50 "S" "SIP+D2U" "" _sip._udp.i-sbe.example.org 656 5. Given the lower order for TCP in the NAPTR response, O-SBE 657 decides to use TCP for transport protocol, so it sends a DNS 658 query for the SRV record for "_sip._tcp.i-sbe.example.org". 660 ;; priority weight port target 661 IN SRV 0 1 5060 i-sbe1.example.org 662 IN SRV 0 2 5060 i-sbe2.example.org 664 6. O-SBE sends a DNS query for "i-sbe1.example.org" to get the 665 A-Record: 667 ;; DNS ANSWER 668 i-sbe1.example.org A 192.0.2.10 669 i-sbe1.example.org A 192.0.2.11 671 7. O-SBE sends the INVITE to I-SBE. O-SBE is the entry point to 672 the O-SSP domain, so it should ensure subsequent mid-dialog 673 requests traverse via itself. If O-SBE chooses to act as B2BUA, 674 it will terminate the call and generate a new back-to-back 675 INVITE request. If O-SBC chooses to act as proxy, it should 676 record-route to stay in the call path. In this example, O-SBE 677 is a B2BUA. 679 INVITE sip:+19172223333@i-sbe1.example.org;user=phone SIP/2.0 680 Via: SIP/2.0/TCP o-sbe1.example.com:5060 681 ;branch= z9hG4bK2d4zzz; 682 Max-Forwards: 10 683 From: Alice 684 ;tag=54321 685 To: Bob 686 Call-ID: abcde-osbe1@o-sbe1.example.com 687 CSeq: 1 INVITE 688 Contact: 691 8. I-SBE receives the request and queries its internal routing 692 database on the TN. It determines the target belongs to T-SSP. 693 Since I-SBE is a B2BUA, I-SBE generates a new INVITE request to 694 T-SSP. 696 INVITE sip:+19172223333@t-sbe1.example.net;user=phone SIP/2.0 697 Via: SIP/2.0/TCP i-sbe1.example.com:5060 698 ;branch= z9hG4bK2d4777; 699 Max-Forwards: 10 700 From: Alice 701 ;tag=54321 702 To: Bob 703 Call-ID: abcde-isbe1@i-sbe1.example.org 704 CSeq: 1 INVITE 705 Contact: 708 Note that I-SSP wants the media to traverse through the I-DBE, 709 I-SBE must modify the SDP in the Offer to point to its DBE. 711 9. T-SBE determines called party home proxy and directs call to 712 called party. T-SBE may use ENUM or other internal mechanism to 713 locate the home proxy. If T-SSP uses ENUM, this internal ENUM 714 entry is different from the external ENUM entry populated for 715 O-SSP. For internal use, it should return the home proxy of 716 UAS. For external use, it should return T-SBE. 718 $ORIGIN 3.3.3.3.2.2.2.7.1.9.1.example.net 719 NATPTR 10 100 "u" "E2U+SIP" 720 "!^.* !sip:+19172223333@t-proxy.example.net!" 722 10. T-SBE receives the NAPTR record and query DNS for the 723 "t-proxy.example.net". The DNS returns an A-Record: 725 ;; DNS ANSWER 726 t-proxy.example.net A 192.0.2.20 728 11. T-SBE sends the INVITE to UAS's home proxy: 730 INVITE sip:+19172223333@t-proxy.example.net;user=phone SIP/2.0 731 Via: SIP/2.0/TCP t-sbe1.example.net:5060 732 ;branch= z9hG4bK28uyyy; 733 Max-Forwards: 10 734 Record-Route: 735 From: Alice 736 ;tag=54321 737 To: Bob 738 Call-ID: abcde-tsbe1@t-sbe1.example.net 739 CSeq: 1 INVITE 740 Contact: 743 12. Finally, UAS's home proxy forwards the INVITE request to UAS. 744 13. RTP is established between UAC and UAS. 746 5.1.3.1. Administrative characteristics 748 This use case looks very similar to Static Direct Peering with 749 Assisted LUF and LRF. The major difference is O-SSP and T-SSP do not 750 have direct L5 connectivity. Instead, O-SSP connects to T-SSP 751 indirectly via I-SSP. 753 O-SSP uses this use case when it uses different I-SSP to reach 754 different T-SSP. Typically, LUF/LRF provider serves multiple O-SSP. 755 Two O-SSP may use different I-SSP to reach the same T-SSP. For 756 example, O-SSP1 may use I-SSP1 to reach T-SSP, but O-SSP2 may use 757 I-SSP2 to reach T-SSP. In other words, given the O-SSP and T-SSP 758 pair as input, LUF/LRF provider will return the SED of I-SSP that is 759 trusted by O-SSP to forward the request to T-SSP. 761 There are two levels of trust relationship. First trust relationship 762 between O-SSP and LUF/LRF provider. LUF/LRF provider provides LUF 763 and LRF for O-SSP. Once O-SSP queries the SED, LUF/LRF provider is 764 out of the picture. Second trust relationship is between O-SSP and 765 I-SSP. I-SSP provides L5 connectivity to assist O-SSP to reach 766 T-SSP. O-SSP and I-SSP have a pre-association for policy before 767 peering happened. Although Figure 4 shows a single provider to 768 provide both LUR/LRF and I-SSP, O-SSP can choose two different 769 providers. 771 5.1.3.2. Options and Nuances 773 Similar to the Static Direct Peering Use Case, O-SSP and T-SSP may 774 deploy SBE and DBE for NAT traversal, security, transcoding, etc. 775 I-SSP can also deploy SBE and DBE for similar reasons. (as depicted 776 in Figure 5) 778 5.1.4. Static Indirect Peering Use Case 780 This use case O-SSP uses its internal LUF/LRF. One of the reasons of 781 using internal LUF/LRF is to control the routing database. By 782 controlling the database, O-SSP can apply different routing rules and 783 policies to different T-SSPs. For example, O-SSP can use I-SSP1 and 784 Policy-1 to reach T-SSP1, and use I-SSP2 and Policy-2 to reach 785 T-SSP2. The challenge for O-SSP is to decide which I-SSP should be 786 used to reach T-SSP. O-SSP could manually enter I-SSP information in 787 the routing database. However, when O-SSP peers to multiple I-SSP, 788 O-SSP may have multiple routes to reach the same T-SSP. If we 789 further consider that an I-SSP may use another I-SSP to reach T-SSP, 790 the permutation can grow exponentially. This is similar to the IP 791 routing problem eventually solved by BGP [RFC4271]. TRIP [RFC3219] 792 is a candidate to solve this problem. However, market has yet to 793 deploy TRIP in large scale. 795 +--------------------+-------------------+---------------------+ 796 | O-SSP | I-SSP | T-SSP | 797 | +-----+ | | +-----+ | 798 | -+O-LUF| | | |T-LUF| | 799 | / |O-LRF+\ | | +----+T-LRF| | 800 | / +-----+ \ | | / +-----+ | 801 | /(2) \(4,5,6) | /(9,10) | 802 |+-------+ +-----+ +-----+ +-----+ +-------+| 803 ||O-Proxy|-(3)-|O-SBE+--(7)-+I-SBE+-(8)--+T-SBE+-(11)-|T-Proxy|| 804 |+-------+ +-----+ +-----+ +-----+ +-------+| 805 | | | | | | 806 | (1) | | (12) | 807 | | | | | | 808 | +-----+ +-----+ +-----+ +-----+ +-----+ | 809 | | UAC +=(13)=+0-DBE+======+I-DBE+======+T-DBE+=======+ UAS | | 810 | +-----+ +-----+ +-----+ +-----+ +-----+ | 811 +--------------------------------------------------------------+ 812 example.com example.org example.net 814 Indirect Peering via I-SSP (SIP and media) 816 Figure 5 818 5.1.4.1. Administrative characteristics 820 The Static Indirect Use Case is implemented in cases where no direct 821 interconnection exists between originating and terminating domains 822 due to either business or physical constraints. 824 O-SSP <---> I-SSP = Relationship O-I 826 In the O-I relationship, typical policies, features or functions that 827 deem this relationship necessary are number portability, Ubiquity of 828 termination options, security certificate management and masquerading 829 of originating VoIP network gear. 831 T-SSP <---> I-SSP = Relationship T-I 833 In the T-I relationship, typical policies, features or functions 834 observed consist of codec "scrubbing", anonymizing, and transcoding. 835 I-SSP must record-route and stay in the signalling path. T-SSP will 836 not accept message directly sent from O-SSP. 838 5.1.4.2. Options and Nuances 840 In Figure 4, we show I-DBE. This will be used when O-SSP and T-SSP 841 do not have a common code. To involve I-DBE, I-SSP should know the 842 list of codec supported by O-SSP and T-SSP. When I-SBE receives the 843 INVITE, it will make a decision to invoke the I-DBE. Another 844 scenario an I-DBE will be used is if O-SSP uses SRTP [RFC3711] for 845 media and T-SSP does not support SRTP, I-DBE can be used. 847 6. On-demand Peering Use Cases 849 On-demand Peering [I-D.ietf-speermint-terminology] describes two SSPs 850 form the peering relationship without a pre-arranged agreement. 852 6.1. On-demand Direct Peering Use Case 854 The basis of this use case is built on the fact that there is NOT a 855 pre-established relationship between the O-SSP and the T-SSP. The 856 O-SSP and T-SSP did not share any information prior to the dialog 857 initiation request. When the O-Proxy invokes the LUF and LRF on the 858 R-URI, the terminating user information must be publicly available. 859 Besides, when the O-Proxy routes the request to the T-Proxy, the 860 T-Proxy must accept the request without any pre-association with 861 O-SSP. 863 6.1.1. Administrative characteristics 865 The On-demand Direct Peering Use Case is typically implemented in a 866 scenario where the T-SSP allows any O-SSP to reach its serving 867 subscribers. T-SSP administrative domain does not require any pre- 868 arranged agreement to accept the call. T-SSP makes its subscribers 869 information available in public. This model mimics the Internet 870 email model. Sender does not need an pre-arranged agreement to send 871 email to the receiver. 873 6.1.2. Options and Nuances 875 Similar to Static Direct Peering Use Case, O-SSP and T-SSP can decide 876 to deploy SBE. T-SSP is open to the public, T-SSP should prepare to 877 suffer from the spam problem existing in email system. VoIP spam is 878 considered more annoying than email spam to the subscribers. T-SSP 879 should apply rules to filter spam calls. 881 7. Federations 883 This section discusses the federation concept, explains which 884 technical parameters make up the foundation of a federation and 885 provides examples. 887 The concrete implementation details (e.g. "direct with one SBE" 888 versus "direct with two SBEs") can involve all the use cases thus far 889 described in the document. 891 7.1. Federation Examples 893 This section lists some examples of how federations can operate. 895 7.1.1. Trivial Federations 897 A private peering arrangement between two SSPs is a special case of a 898 federation. These two SSP have agreed to exchange calls amongst 899 themselves and they have set up whatever LUF/LRF/SBE plus Layer 3 900 infrastructure they need to route and complete the calls. This can 901 be in a direct or indirect manner, but usually follows the direct 902 call model. 904 It is thus not needed to treat bi-lateral peering as conceptually 905 different to federation-based peering. 907 On the other extreme, the set of all SSPs implementing an open SIP 908 service according to [RFC3261], [RFC3263], [RFC3761] also fulfills 909 the definition of a federation. In that case, the technical rules 910 are contained in these three RFCs, the LS is the public DNS. Whether 911 some of these SSPs use SBCs as border elements is not relevant. 913 The administrative model of this federation is the "email model": 914 There is no "member list", any SIP server operating on the Internet 915 which implements call routing according to these RFCs is implicitly a 916 member of that federation. No business relationship is needed 917 between "members", thus no money is likely to change hands for 918 terminating calls. There is no contractual protection against 919 nuisance calls, SPIT or denial of service attacks. 921 7.1.2. Access List based Federations 923 If running an open SIP proxy is not desired, then a group of SSPs 924 which want to allow calls from each other can collect the list of IP 925 addresses of all their border elements. 927 This list is redistributed to all members which use it to configure 928 firewalls in front of their ingress elements. Thus calls from other 929 members of this federation are accepted while calls from other hosts 930 on the Internet are blocked. 932 Whether SSPs deploy SBEs as border elements is not relevant. Call 933 routing can still be done via standard RFC rules. 935 Whenever a new member joins this club every other SSP needs to adapt 936 its filter rules. 938 7.1.3. Central SIP Proxy Federations 940 One way to simplify the management of these firewall rules is to 941 route all SIP messages via a central proxy. 943 In that case, all federation members just need to open up their 944 ingress elements to requests from that central server. A new SSP 945 just triggers a change in the configuration of this box and not at 946 all other SSPs. 948 While centralized solutions may entail typical hub-and-spoke 949 architecture considerations, the added overall federation scalability 950 with respect to the number of interconnects required, their 951 associated policies and management make this approach quite popular 952 today. 954 This is an example of Indirect Peering. 956 7.1.4. Architecture, scalability and business scalability 958 The network architecture which in the case centralized model would 959 reflect a hub and spoke model - should be weighed against a 960 distributed model. While such a centralized model presents well- 961 known network and server scalability challenges, a distributed model 962 requires higher interconnection complexity, reflected in provisioning 963 and the need for the maintenance of such relationships. 965 8. Acknowledgments 967 This draft is a consolidation of many early individual drafts. 968 Michael Haberler, Mike Mammer, Otmar Lendl, Rohan Mahy, David 969 Schwartz, Eli Katz and Jeremy Barkan are the authors of the early 970 individal drafts. Besides, Jason Livingood, Daryl Malas, David 971 Meyer, Hadriel Kaplan, John Elwell, Reinaldo Penno, Sohel Khan, James 972 McEachern, Jon Peterson, Alexander Mayrhofer, and Jean-Francois Mule 973 made many valuable comments to this draft. 975 9. Security Considerations 977 This document introduces no new security considerations. However, it 978 is important to note that session interconnect, as described in this 979 document, has a wide variety of security issues that should be 980 considered in documents addressing both protocol and use case 981 analyzes. 983 10. IANA Considerations 985 This document creates no new requirements on IANA namespaces 986 [RFC5226]. 988 11. References 990 11.1. Normative References 992 [I-D.lee-speermint-use-case-cable] 993 Lee, Y., "Session Peering Use Case for Cable", 994 draft-lee-speermint-use-case-cable-01 (work in progress), 995 September 2006. 997 [I-D.lendl-speermint-federations] 998 Lendl, O., "A Federation based VoIP Peering Architecture", 999 draft-lendl-speermint-federations-03 (work in progress), 1000 September 2006. 1002 [I-D.mahy-speermint-direct-peering] 1003 Mahy, R., "A Minimalist Approach to Direct Peering", 1004 draft-mahy-speermint-direct-peering-02 (work in progress), 1005 July 2007. 1007 [I-D.schwartz-speermint-use-cases-federations] 1008 Schwartz, D., "Session Peering Use Cases for Federations", 1009 draft-schwartz-speermint-use-cases-federations-00 (work in 1010 progress), November 2006. 1012 [I-D.uzelac-speermint-use-cases] 1013 Uzelac, A., "SIP Peering Use Case for VSPs", 1014 draft-uzelac-speermint-use-cases-00 (work in progress), 1015 October 2006. 1017 [I-D.ietf-speermint-terminology] 1018 Malas, D. and D. Meyer, "SPEERMINT Terminology", 1019 draft-ietf-speermint-terminology-16 (work in progress), 1020 February 2008. 1022 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1023 E. Lear, "Address Allocation for Private Internets", 1024 BCP 5, RFC 1918, February 1996. 1026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1027 Requirement Levels", BCP 14, RFC 2119, March 1997. 1029 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1030 A., Peterson, J., Sparks, R., Handley, M., and E. 1031 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1032 June 2002. 1034 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1035 Protocol (SIP): Locating SIP Servers", RFC 3263, 1036 June 2002. 1038 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 1039 Resource Identifiers (URI) Dynamic Delegation Discovery 1040 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 1042 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1043 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1044 May 2008. 1046 11.2. Informative References 1048 [I-D.lewis-peppermint-enum-reg-if] 1049 Lewis, E., "ENUM Registry Interface Requirements", 1050 draft-lewis-peppermint-enum-reg-if-01 (work in progress), 1051 November 2007. 1053 [I-D.newton-peppermint-problem-statement] 1054 Newton, A., "Provisioning Extensions in Peering Registries 1055 for Multimedia Interconnection (PEPPERMINT) Problem 1056 Statement", draft-newton-peppermint-problem-statement-00 1057 (work in progress), January 2007. 1059 [I-D.schwartz-peppermint-problem-statement] 1060 Schwartz, D., Mahy, R., Duric, A., and E. Lewis, 1061 "Consolidated Provisioning Problem Statement", 1062 draft-schwartz-peppermint-problem-statement-00 (work in 1063 progress), February 2008. 1065 [RFC3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony 1066 Routing over IP (TRIP)", RFC 3219, January 2002. 1068 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1069 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1070 RFC 3711, March 2004. 1072 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1073 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1075 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1076 and T. Wright, "Transport Layer Security (TLS) 1077 Extensions", RFC 4366, April 2006. 1079 Authors' Addresses 1081 Adam Uzelac (editor) 1082 Global Crossing 1083 U.S.A. 1085 Email: adam.uzelac@globalcrossing.com 1086 URI: http://www.globalcrossing.com 1088 Yiu L.Lee (editor) 1089 Comcast Cable 1090 U.S.A. 1092 Email: yiu_lee@cable.comcast.com 1093 URI: http://www.comcast.com 1095 Full Copyright Statement 1097 Copyright (C) The IETF Trust (2008). 1099 This document is subject to the rights, licenses and restrictions 1100 contained in BCP 78, and except as set forth therein, the authors 1101 retain all their rights. 1103 This document and the information contained herein are provided on an 1104 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1105 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1106 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1107 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1108 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1109 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1111 Intellectual Property 1113 The IETF takes no position regarding the validity or scope of any 1114 Intellectual Property Rights or other rights that might be claimed to 1115 pertain to the implementation or use of the technology described in 1116 this document or the extent to which any license under such rights 1117 might or might not be available; nor does it represent that it has 1118 made any independent effort to identify any such rights. Information 1119 on the procedures with respect to rights in RFC documents can be 1120 found in BCP 78 and BCP 79. 1122 Copies of IPR disclosures made to the IETF Secretariat and any 1123 assurances of licenses to be made available, or the result of an 1124 attempt made to obtain a general license or permission for the use of 1125 such proprietary rights by implementers or users of this 1126 specification can be obtained from the IETF on-line IPR repository at 1127 http://www.ietf.org/ipr. 1129 The IETF invites any interested party to bring to its attention any 1130 copyrights, patents or patent applications, or other proprietary 1131 rights that may cover technology that may be required to implement 1132 this standard. Please address the information to the IETF at 1133 ietf-ipr@ietf.org.