idnits 2.17.1 draft-ietf-speermint-architecture-05.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 866. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack 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.) -- The document date (February 24, 2008) is 5903 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '24' is mentioned on line 595, but not defined == Unused Reference: '2' is defined on line 730, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 740, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 744, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 778, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 784, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 787, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 791, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 794, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2915 (ref. '2') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 4366 (ref. '5') (Obsoleted by RFC 5246, RFC 6066) == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-03 == Outdated reference: A later version (-05) exists of draft-ietf-speermint-flows-02 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Speermint Working Group R. Penno 2 Internet Draft Juniper Networks 3 Intended status: Informational D. Malas 4 Expires: August 2008 Level 3 5 S. Khan 6 Comcast 7 A. Uzelac 8 Global Crossing 9 February 24, 2008 11 SPEERMINT Peering Architecture 12 draft-ietf-speermint-architecture-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that 17 any applicable patent or other IPR claims of which he or she is 18 aware have been or will be disclosed, and any of which he or she 19 becomes aware will be disclosed, in accordance with Section 6 of 20 BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on January 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document defines the SPEERMINT peering architecture, its 47 functional components and peering interface functions. It also 48 describes the steps taken to establish a session between two peering 49 domains in the context of the functions defined. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119[1] 57 Table of Contents 59 1. Introduction...................................................3 60 2. Network Context................................................4 61 3. Procedures.....................................................5 62 4. Reference SPEERMINT Architecture...............................6 63 5. Peer Function Examples.........................................8 64 5.1. The Location Function (LF) of an Initiating Provider......8 65 5.1.1. Target address analysis..............................8 66 5.1.2. User ENUM Lookup.....................................9 67 5.1.3. Carrier ENUM lookup.................................10 68 5.1.4. Routing Table.......................................10 69 5.1.5. SIP DNS Resolution..................................10 70 5.1.6. SIP Redirect Server.................................11 71 5.2. The Location Function (LF) of a Receiving Provider.......11 72 5.2.1. Publish ENUM records................................11 73 5.2.2. Publish SIP DNS records.............................11 74 5.2.3. Subscribe Notify....................................11 75 5.3. Signaling Function (SF)..................................11 76 5.4. The Signaling Function (SF) of an Initiating Provider....12 77 5.4.1. Setup TLS connection................................12 78 5.4.2. IPSec...............................................12 79 5.4.3. Co-Location.........................................12 80 5.4.4. Send the SIP request................................12 81 5.5. The Signaling Function (SF) of an Initiating Provider....14 82 5.5.1. Verify TLS connection...............................14 83 5.5.2. Receive SIP requests................................14 84 5.6. Media Function (MF)......................................15 85 5.7. Policy Considerations....................................15 86 6. Call Control and Media Control Deployment Options.............16 87 7. Address space considerations..................................17 88 8. Security Considerations.......................................17 89 9. IANA Considerations...........................................18 90 10. Acknowledgments..............................................18 91 11. References...................................................19 92 11.1. Normative References....................................19 93 11.2. Informative References..................................20 94 Author's Addresses...............................................21 95 Intellectual Property Statement..................................21 96 Disclaimer of Validity...........................................22 98 1. Introduction 100 The objective of this document is to define a reference peering 101 architecture in the context of Session PEERing for Multimedia 102 INTerconnect (SPEERMINT). In this process, we define the peering 103 reference architecture (reference, for short), it's functional 104 components, and peering interface functions from the perspective of 105 a SIP [3] Service provider's (SSP) network. 107 This architecture allows the interconnection of two SSPs in layer 5 108 peering as defined in the SPEERMINT Requirements [13] and 109 Terminology [12] documents. 111 Layer 3 peering is outside the scope of this document. Hence, the 112 figures in this document do not show routers so that the focus is on 113 Layer 5 protocol aspects. 115 This document uses terminology defined in the SPEERMINT Terminology 116 document [12], so the reader should be familiar with all the terms 117 defined there. 119 2. Network Context 121 Figure 1 shows an example network context. Two SSPs can form a Layer 122 5 peering over either the public Internet or private Layer3 123 networks. In addition, two or more providers may form a SIP (Layer 124 5) federation [13] on either the public Internet or private Layer 3 125 networks. This document does not make any assumption whether the SIP 126 providers directly peer to each other or through Layer 3 transit 127 network as per use case of [16]. 129 Note that Figure 1 allows for the following potential SPEERMINT 130 peering scenarios: 132 o Enterprise to Enterprise across the public Internet 134 o Enterprise to SSP across the public Internet 136 o SSP to SSP across the public Internet 138 o Enterprise to enterprise across a private Layer 3 network 140 o Enterprise to SSP across a private Layer 3 network 142 o SSP to SSP across a private Layer 3 network 144 The members of a federation may jointly use a set of functions such 145 as location function, signaling function, media function, ENUM 146 database or SIP Registrar, SIP proxies, and/or functions that 147 synthesize various SIP and non-SIP based applications. Similarly, 148 two SSPs may jointly use a set of functions. The functions can be 149 either public or private. 151 +-------------------+ 152 | | 153 | Public | 154 | Peering | 155 | Function | 156 | | 157 +-------------------+ 158 | 159 ----- 160 +-----------+ / \ +-----------+ 161 |Enterprise | -- -- |Enterprise | 162 |Provider A |-----------/ \-----------|Provider B | 163 +-----------+ -- -- +-----------+ 164 / Public \ 165 | Internet | 166 \ (Layer 3) / 167 +-----------+ -- -- +-----------+ 168 |Service |-----------\ /-----------|Service | 169 |Provider C | -- -- |Provider D | 170 +-----------+ \_____/ +-----------+ 171 | Layer 3 Peering 172 | Point (out of scope) 173 ----- 174 +-----------+ / \ +-----------+ 175 |Enterprise | -- -- |Enterprise | 176 |Provider E |-----------/ \-----------|Provider F | 177 +-----------+ -- Private -- +-----------+ 178 / Network \ 179 | (Layer 3) | 180 \ / 181 +-----------+ -- -- +-----------+ 182 | SSP G |-----------\ /-----------| SSP H | 183 | | -- -- | | 184 +-----------+ \____/ +-----------+ 185 | 186 +-------------------+ 187 | Private | 188 | SIP | 189 | Peering | 190 | | 191 +-------------------+ 193 Figure 1: SPEERMINT Network Context 195 3. Procedures 197 This document assumes that a call from a UAC end user in the 198 initiating peer's network goes through the following steps to 199 establish a call to a UAS in the receiving peer's network: 201 1. The analysis of a target address. 203 a. If the target address represents an intra-SSP resource, 204 we go directly to step 4. 206 2. the discovery of the receiving peering point address, 208 3. the enforcement of authentication and potentially other 209 policies, 211 4. the discovery of the UAS, 213 5. the routing of SIP messages, 215 6. the session establishment, 217 7. the transfer of media which could include voice, video, text 218 and others, 220 8. and the session termination. 222 4. Reference SPEERMINT Architecture 224 Figure 2 depicts the SPEERMINT architecture and logical functions 225 that form the peering between two SSPs. 227 +------+ 228 | DNS, | 229 +---------->| Db, |<---------+ 230 | | etc | | 231 | +------+ | 232 | | 233 ------|-------- -------|------- 234 / v \ / v \ 235 | +--LUF-+ | | +--LUF-+ | 236 | | | | | | | | 237 | | | | | | | | 238 | | | | | | | | 239 | +------+ | | +------+ | 240 | | | | | | 241 | | | | | | 242 | v | | v | 243 | +--LRF-+ | | +--LRF-+ | 244 | | | | | | | | 245 | | | | | | | | 246 | | | | | | | | 247 | +------+ | | +------+ | 248 | \ | | / | 249 | `. | | / | 250 | \ | | .' | 251 | `. +---SF--+ +---SF--+ / | 252 | \| | | | / | 253 | | SBE | | SBE | | 254 | Originating | | | | Target | 255 | +---SF--+ +---SF--+ | 256 | SSP | | SSP | 257 | +---MF--+ +---MF--+ | 258 | | | | | | 259 | | DBE | | DBE | | 260 | | | | | | 261 | +---MF--+ +---MF--+ | 262 \ / \ / 263 --------------- --------------- 264 Figure 2: Reference SPEERMINT Architecture 266 The procedures presented in Chapter 3 are implemented by a set of 267 peering functions: 269 The Look-Up Function (LUF) provides a mechanism for determining for 270 a given request the target domain to which the request should be 271 routed. 273 The Location Routing Function (LRF) determines for the target domain 274 of a given request the location of the SF in that domain and 275 optionally develops other SED required to route the request to that 276 domain. 278 Location Function (LF): The Location functions is composed of the 279 LUF and LRF functions 281 Signaling Function (SF): Purpose is to perform SIP call routing, to 282 optionally perform termination and re-initiation of call, to 283 optionally implement security and policies on SIP messages, and to 284 assist in discovery/exchange of parameters to be used by the Media 285 Function (MF). 287 Media Function (MF): Purpose is to perform media related function 288 such as media transcoding and media security implementation between 289 two SIP providers. 291 The intention of defining these functions is to provide a framework 292 for design segmentation and allow each one to evolve independently. 294 5. Peer Function Examples 296 This section describes the functions in more detail and provides 297 some examples on the role they would play in a SIP call in a Layer 5 298 peering scenario. 300 Some of the information in the chapter is taken from [14] and is put 301 here for continuity purposes. 303 5.1. The Location Function (LF) of an Initiating Provider 305 Purpose is to determine the SF of the target domain of a given 306 request and optionally develop Session Establishment Data (SED) 307 [12]. The LF of an Initiating SSP analyzes target address and 308 discovers the next hop signaling function (SF) in a peering 309 relationship using the Look-Up Function. The resource to determine 310 the SF of the target domain might be provided by a third-party as in 311 the assisted-peering case. 313 5.1.1. Target address analysis 314 When the initiating SSP receives a request to communicate, it 315 analyzes the target state data to determine whether the call needs 316 to be terminated internal or external to its network. The analysis 317 method is internal to the SSP; thus, outside the scope of SPEERMINT. 318 Note that the SSP is free to consult any manner of private data 319 sources to make this determination. 321 If the target address does not represent a resource inside the 322 initiating SSP's administrative domain or federation of domains, the 323 initiating SSP resolves the call routing data by using the Location 324 Function (LF). 326 If the request to communicate is for an im: or pres: URI type, the 327 initiating peer follows the procedures in [8]. If the highest 328 priority supported URI scheme is sip: or sips:, the initiating peer 329 skips to SIP DNS resolution in Section 5.1.5. Likewise, if the 330 target address is already a sip: or sips: URI in an external domain, 331 the initiating peer skips to SIP DNS resolution in Section 5.1.5. 333 If the target address corresponds to a specific E.164 address, the 334 peer may need to perform some form of number plan mapping according 335 to local policy. For example, in the United States, a dial string 336 beginning "011 44" could be converted to "+44", or in the United 337 Kingdom "00 1" could be converted to "+1". Once the peer has an 338 E.164 address, it can use ENUM. 340 5.1.2. User ENUM Lookup 342 If an external E.164 address is the target, the initiating peer 343 consults the public "User ENUM" rooted at e164.arpa, according to 344 the procedures described in RFC 3761. The peer MUST query for the 345 "E2U+sip" enumservice as described in RFC 3764 [11], but MAY check 346 for other enumservices. The initiating peer MAY consult a cache or 347 alternate representation of the ENUM data rather than actual DNS 348 queries. Also, the peer MAY skip actual DNS queries if the 349 initiating peer is sure that the target address country code is not 350 represented in e164.arpa. If a sip: or sips: URI is chosen the peer 351 skips to Section 5.1.5. 353 If an im: or pres: URI is chosen for based on an "E2U+im" [10] or 354 "E2U+pres" [9] enumserver, the peer follows the procedures for 355 resolving these URIs to URIs for specific protocols such a SIP or 356 XMPP as described in the previous section. 358 5.1.3. Infrastructure ENUM lookup 360 Next the initiating peer checks for a carrier-of-record in a carrier 361 ENUM domain according to the procedures described in [12]. As in 362 the previous step, the peer MAY consult a cache or alternate 363 representation of the ENUM data in lieu of actual DNS queries. The 364 peer first checks for records for the "E2U+sip" enumservice, then 365 for the "E2U+pstn" enumservice as defined in [21]. If a terminal 366 record is found with a sip: or sips: URI, the peer skips to Section 367 5.1.5, otherwise the peer continues processing according to the next 368 section. 370 5.1.4. Routing Table 372 If there is no user ENUM records and the initiating peer cannot 373 discover the carrier-of-record or if the initiating peer cannot 374 reach the carrier-of-record via SIP peering, the initiating peer 375 still needs to deliver the call to the PSTN or reject it. Note that 376 the initiating peer MAY still forward the call to another SSP for 377 PSTN gateway termination by prior arrangement using the routing 378 table. 380 If so, the initiating peer rewrites the Request-URI to address the 381 gateway resource in the target SSP's domain and MAY forward the 382 request on to that SSP using the procedures described in the 383 remainder of these steps. 385 5.1.5. SIP DNS Resolution 387 Once a sip: or sips: in an external domain is selected as the 388 target, the initiating peer MAY apply local policy to decide whether 389 forwarding requests to the target domain is acceptable. If so, the 390 initiating peer uses the procedures in RFC 3263 [4] Section 4 to 391 determine how to contact the receiving peer. To summarize the RFC 392 3263 procedure: unless these are explicitly encoded in the target 393 URI, a transport is chosen using NAPTR records, a port is chosen 394 using SRV records, and an address is chosen using A or AAAA records. 395 Note that these are queries of records in the global DNS. 397 When communicating with a public external peer, entities compliant 398 to this document MUST only select a TLS-protected transport for 399 communication from the initiating peer to the receiving peer. Note 400 that this is a single-hop requirement. Either peer MAY insist on 401 using a sips: URI which asserts that each hop is TLS-protected, but 402 this document does not require protection over each hop. 404 5.1.6. SIP Redirect Server 406 A SIP Redirect Server may help in resolving the current address of a 407 UAS. 409 5.2. The Location Function (LF) of a Receiving Provider 411 5.2.1. Publish ENUM records 413 The receiving peer SHOULD participate by publishing "E2U+sip" and 414 "E2U+pstn" records with sip: or sips: URIs wherever a public carrier 415 ENUM root is available. This assumes that the receiving peer wants 416 to peer by default. When the receiving peer does not want to accept 417 traffic from specific initiating peers, it MAY still reject requests 418 on a call-by-call basis. 420 5.2.2. Publish SIP DNS records 422 To receive peer requests, the receiving peer MUST insure that it 423 publishes appropriate NAPTR, SRV, and address (A and/or AAAA) 424 records in the LF relevant to the peer's SF. 426 5.2.3. Subscribe Notify 428 Policies function may also be optionally implemented by dynamic 429 subscribe, notify, and exchange of policy information and feature 430 information among SSPs [22]. 432 5.3. Signaling Function (SF) 434 The purpose of signaling function is to perform routing of SIP 435 messages, to optionally perform termination and re-initiation of a 436 call, to optionally implement security and policies on SIP messages, 437 and to assist in discovery/exchange of parameters to be used by the 438 Media Function (MF). 440 The signaling function perform the routing of SIP messages. The 441 optional termination and re-initiation of calls are performed by the 442 signaling path border element (SBE). 444 Optionally, a SF may perform additional functions such as Session 445 Admission Control, SIP Denial of Service protection, SIP Topology 446 Hiding, SIP header normalization, and SIP security, privacy and 447 encryption. 449 The SF can also process SDP payloads for media information such as 450 media type, bandwidth, and type of codec; then, communicate this 451 information to the media function. Signaling function may optionally 452 communicate with the network to pass Layer 3 related policies [10] 454 5.4. The Signaling Function (SF) of an Initiating Provider 456 5.4.1. Setup TLS connection 458 Once a transport, port, and address are found, the initiating SSP 459 will open or find a reusable TLS connection to the peer. The 460 initiating provider MUST verify the server certificate that SHOULD 461 be rooted in a well-known certificate authority. The initiating SSP 462 MUST be prepared to provide a TLS client certificate upon request 463 during the TLS handshake. The client certificate MUST contain a DNS 464 or URI choice type in the subjectAltName which corresponds to the 465 domain asserted in the host production of the From header URI. The 466 certificate SHOULD be valid and rooted in a well-known certificate 467 authority. 469 Note that the client certificate MAY contain a list of entries in 470 the subjectAltName, only one of which has to match the domain in the 471 From header URI. 473 5.4.2. IPSec 475 In certain deployments the use of IPSec between the signaling 476 functions of the originating and terminating domains can be used as 477 a security mechanism instead of TLS. 479 5.4.3. Co-Location 481 In this scenario the SFs are co-located in a 482 physically secure location and/or are members of a segregated 483 network. In this case messages between the originating and 484 terminating SSPs would be sent as clear text. 486 5.4.4. Send the SIP request 488 Once a TLS connection between the peers is established, the 489 initiating peer sends the request. When sending some requests, the 490 initiating peer MUST verify and assert the senders identity using 491 the SIP Identity mechanism. 493 The domain name in the URI of the From: header MUST be a domain 494 which was present in the certificate provided when establishing the 495 TLS connection for this request, even if the user part has an 496 anonymous value. If the From header contains the user URI parameter 497 with the value of "phone", the user part of the From header URI MUST 498 be a complete and valid tel: URI [9] telephone-subscriber 499 production, and SHOULD be a global-number. For example, the 500 following are all acceptable and the first three are encouraged: 502 From: "John Doe" john.doe@example.net 504 From: "+12125551212" <+12125551212@example.net;user=phone> 506 From: "Anonymous" 508 From: <4092;phone-context=+12125554000@example.net;user=phone> 510 From: "5551212" <5551212@example.net> 512 The following are not acceptable: 514 From: "2125551212" <2125551212@example.net;user=phone> 516 From: "Anonymous" 518 In addition, new requests MUST contain a valid Identity and 519 Identity-Info header as described in [12]. The Identity-Info header 520 must present a domain name that is represented in the certificate 521 provided when establishing the TLS connection over which the request 522 is sent. The initiating peer SHOULD include an Identity header on 523 in-dialog requests as well, if the From header field value matches 524 an identity the initiating peer is willing to assert. 526 The initiating peer MAY include any SIP option-tags in Supported, 527 Require, or Proxy-Require headers according to procedures in 528 standards-track SIP extensions. Note however that the initiating 529 peer MUST be prepared to fallback to baseline SIP functionality as 530 defined by the mandatory-to-implement features of RFC 3261, RFC 531 3263,and RFC 3264 [7], except that peers implementing this 532 specification MUST implement SIP over TLS using the sip: URI scheme, 533 the SIP Identity header, and RFC 4320 [10] non-INVITE transaction 534 fixes. 536 5.5. The Signaling Function (SF) of an Target Provider 538 5.5.1. Verify TLS connection 540 When the receiving peer receives a TLS client hello, it responds 541 with its certificate. The receiving peer certificate SHOULD be 542 valid and rooted in a well-known certificate authority. The 543 receiving peer MUST request and verify the client certificate during 544 the TLS handshake. 546 Once the initiating peer has been authenticated, the receiving peer 547 can authorize communication from this peer based on the domain name 548 of the peer and the root of its certificate. This allows two 549 authorization models to be used, together or separately. In the 550 domain-based model, the receiving peer can allow communication from 551 peers with some trusted administrative domains that use general- 552 purpose certificate authorities, without explicitly permitting all 553 domains with certificates rooted in the same authority. It also 554 allows a certificate authority (CA) based model where every domain 555 with a valid certificate rooted in some list of CAs is automatically 556 authorized. 558 5.5.2. Receive SIP requests 560 Once a TLS connection is established, the receiving peer is prepared 561 to receive incoming SIP requests. For new requests (dialog forming 562 or not) the receiving peer verifies that the target (request-URI) is 563 a domain that for which it is responsible. For these requests, there 564 should be no remaining Route header field values. Next the receiving 565 verifies that the Identity header is valid, corresponds to the 566 message, and corresponds to the Identity-Info header, and that the 567 domain in the From header corresponds to one of the domains in the 568 TLS client certificate. 570 For in-dialog requests, the receiving peer can verify that it 571 corresponds to the top-most Route header field value. The peer also 572 validates any Identity header if present. 574 The receiving peer MAY reject incoming requests due to local policy. 575 When a request is rejected because the initiating peer is not 576 authorized to peer, the receiving peer SHOULD respond with a 403 577 response with the reason phrase "Unsupported Peer". 579 5.6. Media Function (MF) 581 The purpose of the MF is to perform media related functions such as 582 media transcoding and media security implementation between two 583 SSPs. 585 An Example of this is to transform a voice payload from one codec 586 (e.g., G.711) to another (e.g., EvRC). Additionally, the MF MAY 587 perform media relaying, media security, privacy, and encryption. 589 5.7. Policy Considerations 591 In the context of the SPEERMINT working group when two SSPs peer, 592 there MAY be a desire to exchange peering policy information 593 dynamically. There are specifications in progress in the SIPPING 594 working group to define policy exchange between an UA and a domain 595 [23] and providing profile data to SIP user agents [24] These 596 considerations borrow from both. 598 Following the terminology introduced in [12], this package uses the 599 terms Peering Session-Independent and Session-Specific policies in 600 the following context. 602 o Peering Session-Independent policies include Diffserv Marking, 603 Policing, Session Admission Control, and domain reachabilities, 604 amongst others. The time period between Peering Session- 605 Independent policy changes is much greater than the time it 606 takes to establish a call. 608 o Peering Session-Specific polices includes supported 609 connection/call rate, total number of connections/calls 610 available, current utilization, amongst others. Peering 611 Session-specific policies can change within the time it takes 612 to establish a call. 614 These policies can be Peer dependent or independent, creating the 615 following peering policy tree definition: 617 o Peer Independent 618 Session dependent 619 Session independent 621 o Peer Dependent 622 Session dependent 623 Session independent 625 6. Call Control and Media Control Deployment Options 627 The peering functions can either be deployed along the following two 628 dimensions depending upon how the signaling function and the media 629 function along with IP functions are implemented: 631 Composed or Decomposed: Addresses the question whether the media 632 must flow through the same physical and geographic elements as SIP 633 dialogs and sessions. 635 Centralized or Distributed: Addresses the question whether the 636 logical and physical peering points are in one geographical location 637 or distributed to multiple physical locations on the SSP's network. 639 In a composed model, SF and MF functions are implemented in one 640 peering logical element. 642 Provider A Provider B 643 ---------- . . ---------- 644 / \ . . / \ 645 | | . _ . | | 646 | +----+ . / \_ . +----+ | 647 | | SF |<-----/ \------| SF | | 648 | +-+--+ . /Transit\ . | | | 649 | | | . / IP \ . | | | 650 | +-+--+ . \ Provider| . | | | 651 | | MF |<~~~~\(Option)|~~~~| MF | | 652 | +----+ . \ / . +----+ | 653 | | . \__ _/ . | | 654 \_________ / . . \________ _/ 655 ---------- ---------- 657 --- Signal (SIP) 658 ~~~ Bearer (RTP/IP) 659 ... Scope of peering 661 Figure 3: Decomposed v. Collapsed Peering 663 The advantage of a collapsed peering architecture is that one- 664 element solves all peering issues. Disadvantage examples of this 665 architecture are single point of failure, bottleneck, and complex 666 scalability. 668 In a decomposed model, SF and MF are implemented in separate peering 669 logical elements. SFs are implemented in a proxy and MFs are 670 implemented in another logical element. The scaling of signaling 671 versus scaling of media may differ between applications. 672 Decomposing allows each to follow a separate migration path. 674 This model allows the implementation of M:N model where one SF is 675 associated with multiple peering MF and one peering MF is associated 676 with multiple peering proxies. Generally, a vertical protocol 677 associates the relationship between a SF and a MF. This architecture 678 reduces the potential of a single point of failure. It allows 679 separation of the policy decision point and the policy enforcement 680 point. An example of disadvantages is the scaling complexity because 681 of the M:N relationship and latency due to the vertical control 682 messages between entities. 684 7. Address space considerations 686 Peering must occur in a common address space, which is defined by 687 the federation, which may be entirely on the public Internet, or 688 some private address space. The origination or termination networks 689 may or may not entirely be in that same address space. If they are 690 not, then a network address translation (NAT) or similar may be 691 needed before the signaling or media is presented correctly to the 692 federation. The only requirement is that all associated entities 693 across the peering interface are reachable. 695 8. Security Considerations 697 In all cases, cryptographic-based security should be maintained as 698 an optional requirement between peering providers conditioned on the 699 presence or absence of underlying physical security of peer 700 connections, e.g. within the same secure physical building. 702 In order to maintain a consistent approach, unique and specialized 703 security requirements common for the majority of peering 704 relationships, should be standardized within the IETF. These 705 standardized methods may enable capabilities such as dynamic peering 706 relationships across publicly maintained interconnections. 708 TODO: Address RFC-3552 BCP items. 710 9. IANA Considerations 712 There are no IANA considerations at this time. 714 10. Acknowledgments 716 The working group thanks Sohel Khan for his initial architecture 717 draft that helped to initiate work on this draft. 719 A significant portion of this draft is taken from [14] with 720 permission from the author R. Mahy. The other important contributor 721 is Otmar Lendl. 723 11. References 725 11.1. Normative References 727 [1] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer 731 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 733 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 734 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 735 Session Initiation Protocol", RFC 3261, June 2002. 737 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 738 (SIP): Locating SIP Servers", RFC 3263, June 2002. 740 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 741 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 742 4366, April 2006. 744 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 745 "RTP: A Transport Protocol for Real-Time Applications", STD 746 64, RFC 3550, July 2003. 748 [7] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 749 numbers with the Session Initiation Protocol (SIP)", RFC 3824, 750 June 2004. 752 [8] Peterson, J., "Address Resolution for Instant Messaging and 753 Presence",RFC 3861, August 2004. 755 [9] Peterson, J., "Telephone Number Mapping (ENUM) Service 756 Registration for Presence Services", RFC 3953, January 2005. 758 [10] ETSI TS 102 333: " Telecommunications and Internet converged 759 Services and Protocols for Advanced Networking (TISPAN); Gate 760 control protocol". 762 [11] Peterson, J., "enumservice registration for Session Initiation 763 Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 765 [12] Livingood, J. and R. Shockey, "IANA Registration for an 766 Enumservice Containing PSTN Signaling Information", RFC 4769, 767 November 2006. 769 11.2. Informative References 771 [13] Malas, D., "SPEERMINT Terminology", draft-ietf-speermint- 772 terminology-16 (work in progress), February 2008. 774 [14] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP 775 Interconnection", draft-ietf-speermint-requirements-03.txt, 776 November 2007. 778 [15] Mahy, R., "A Minimalist Approach to Direct Peering", draft- 779 mahy-speermint-direct-peering-02.txt, July 2007. 781 [16] Penno, R., et al., "SPEERMINT Routing Architecture Message 782 Flows", draft-ietf-speermint-flows-02.txt", April 2007. 784 [17] Houri, A., et al., "RTC Provisioning Requirements", draft- 785 houri-speermint-rtc-provisioning-reqs-00.txt, June, 2006. 787 [18] Habler, M., et al., "A Federation based VOIP Peering 788 Architecture", draft-lendl-speermint-federations-03.txt, 789 September 2006. 791 [19] Mahy, R., "A Telephone Number Mapping (ENUM) Service 792 Registration for Instant Messaging (IM) Services", RFC 5028 794 [20] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM 795 in the e164.arpa tree", draft-haberler-carrier-enum-03 (work 796 in progress), March 2006. 798 [21] Penno, R., Malas D., and Melampy, P., "A Session Initiation 799 Protocol (SIP) Event package for Peering", draft-penno- 800 sipping-peering-package-01 (work in progress), September 2006. 802 [22] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", 803 W3C REC REC-xml-names-19990114, January 1999. 805 [23] Burger, E (Ed.), "A Mechanism for Content Indirection in 806 Session Initiation Protocol (SIP) Messages", RFC 4483, May 807 2006 809 Author's Addresses 811 Mike Hammer 812 Cisco Systems 813 13615 Dulles Technology Drive 814 Herndon, VA 20171 815 USA 816 Email: mhammer@cisco.com 818 Sohel Khan, Ph.D. 819 Comcast Cable Communications 820 U.S.A 821 Email: sohel_khan@cable.comcast.com 823 Daryl Malas 824 Level 3 Communications LLC 825 1025 Eldorado Blvd. 826 Broomfield, CO 80021 827 USA 828 EMail: daryl.malas@level3.com 830 Reinaldo Penno (Editor) 831 Juniper Networks 832 1194 N Mathilda Avenue 833 Sunnyvale, CA 834 USA 835 Email: rpenno@juniper.net 837 Adam Uzelac 838 Global Crossing 839 1120 Pittsford Victor Road 840 PITTSFORD, NY 14534 841 USA 842 Email: adam.uzelac@globalcrossing.com 844 Intellectual Property Statement 846 The IETF takes no position regarding the validity or scope of any 847 Intellectual Property Rights or other rights that might be claimed 848 to pertain to the implementation or use of the technology described 849 in this document or the extent to which any license under such 850 rights might or might not be available; nor does it represent that 851 it has made any independent effort to identify any such rights. 852 Information on the procedures with respect to rights in RFC 853 documents can be found in BCP 78 and BCP 79. 855 Copies of IPR disclosures made to the IETF Secretariat and any 856 assurances of licenses to be made available, or the result of an 857 attempt made to obtain a general license or permission for the use 858 of such proprietary rights by implementers or users of this 859 specification can be obtained from the IETF on-line IPR repository 860 at http://www.ietf.org/ipr. 862 The IETF invites any interested party to bring to its attention any 863 copyrights, patents or patent applications, or other proprietary 864 rights that may cover technology that may be required to implement 865 this standard. Please address the information to the IETF at 866 ietf-ipr@ietf.org. 868 Disclaimer of Validity 870 This document and the information contained herein are provided on 871 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 872 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 873 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 874 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 875 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 876 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 877 FOR A PARTICULAR PURPOSE. 879 Copyright Statement 881 Copyright (C) The IETF Trust (2008). 883 This document is subject to the rights, licenses and restrictions 884 contained in BCP 78, and except as set forth therein, the authors 885 retain all their rights. 887 Acknowledgment 889 Funding for the RFC Editor function is currently provided by the 890 Internet Society.