idnits 2.17.1 draft-ietf-speermint-architecture-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 738. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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.) -- The document date (September 18, 2006) is 6423 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 640, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 643, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 654, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 658, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 687, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 700, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 704, 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 3546 (ref. '5') (Obsoleted by RFC 4366) ** Downref: Normative reference to an Informational RFC: RFC 3824 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-04 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-00 == Outdated reference: A later version (-02) exists of draft-mahy-speermint-direct-peering-00 == Outdated reference: A later version (-05) exists of draft-ietf-speermint-flows-00 == Outdated reference: A later version (-01) exists of draft-lee-speermint-use-case-cable-00 == Outdated reference: A later version (-03) exists of draft-ietf-enum-im-service-00 == Outdated reference: A later version (-03) exists of draft-haberler-carrier-enum-02 == Outdated reference: A later version (-05) exists of draft-ietf-enum-pstn-04 == Outdated reference: A later version (-01) exists of draft-penno-sipping-peering-package-00 Summary: 6 errors (**), 0 flaws (~~), 20 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Speermint Working Group R.Penno (Editor) 2 Internet Draft Juniper Networks 3 Expires: March 2007 September 18, 2006 5 SPEERMINT Peering Architecture 6 draft-ietf-speermint-architecture-01 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on November 2006. 34 Abstract 36 This document defines the SPEERMINT peering architecture, its 37 functional components and peering interface functions. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in [1] 45 Table of Contents 47 1. Introduction...................................................2 48 2. Network Context................................................3 49 3. Procedures.....................................................5 50 4. Reference SPEERMINT Architecture...............................5 51 5. Peer Function Examples.........................................7 52 5.1. The Location Function (LF) of an Initiating Provider......7 53 5.1.1. Target address analysis..............................7 54 5.1.2. User ENUM Lookup.....................................8 55 5.1.3. Carrier ENUM lookup..................................8 56 5.1.4. Routing Table........................................8 57 5.1.5. SIP DNS Resolution...................................8 58 5.1.6. SIP Redirect Server..................................9 59 5.2. The Location Function (LF) of a Receiving Provider........9 60 5.2.1. Publish ENUM records.................................9 61 5.2.2. Publish SIP DNS records..............................9 62 5.3. Policy Function (PF)......................................9 63 5.3.1. TLS.................................................11 64 5.3.2. IPSec...............................................11 65 5.3.3. Subscribe Notify....................................11 66 5.4. Signaling Function (SF)..................................11 67 5.5. Media Function (MF)......................................12 68 6. Call Control and Media Control Deployment Options.............12 69 7. Security Considerations.......................................13 70 8. IANA Considerations...........................................14 71 9. Acknowledgments...............................................14 72 Author's Addresses...............................................15 73 10. References...................................................15 74 10.1. Normative References....................................15 75 10.2. Informative References..................................16 76 Intellectual Property Statement..................................17 77 Disclaimer of Validity...........................................18 78 Copyright Statement..............................................18 79 Acknowledgment...................................................18 81 1. Introduction 83 The objective of this document is to define a reference peering 84 architecture in the context of Session PEERing for Multimedia 85 INTerconnect (SPEERMINT). In this process, we define the peering 86 reference architecture (reference, for short), its functional 87 components, and peering interface functions from the perspective of a 88 real-time communications (Voice and Multimedia) IP Service provider 89 network. 91 This architecture allows the interconnection of two service providers 92 in layer 5 peering as defined in the SPEERMINT Requirements [13] and 93 Terminology [12] documents for the purpose SIP-based voice and 94 multimedia traffic. 96 Layer 3 peering is outside the scope of this document. Hence, the 97 figures in this document do not show routers so that the focus is on 98 Layer 5 protocol aspects. 100 This document uses terminology defined in the SPEERMINT Terminology 101 document [12]. 103 2. Network Context 105 Figure 1 shows an example network context. Two SIP providers can form 106 a Layer 5 peer over either the public Internet or private Layer 3 107 networks. In addition, two or more providers may form a SIP (Layer 5) 108 federation [17] on either the public Internet or private Layer 3 109 networks. This document does not make any assumption whether the SIP 110 providers directly peer to each other or through Layer 3 transit 111 network as per use case of [16]. 113 Note that Figure 1 allows for the following potential SPEERMINT 114 peering scenarios: 116 o Enterprise to Enterprise across the public Internet 118 o Enterprise to Service Provider across the public Internet 120 o Service Provider to Service Provider across the public Internet 122 o Enterprise to enterprise across a private Layer 3 network 124 o Enterprise to Service Provider across a private Layer 3 network 126 o Service Provider to Service Provider across a private Layer 3 127 network 129 The members of a federation may jointly use a set of functions such 130 as location peering function, application function, subscriber 131 database function, SIP proxies, and/or functions that synthesize 132 various SIP and non-SIP based applications. Similarly, two providers 133 may jointly use a set of peering functions. The federation functions 134 or the peering functions can be either public or private. 136 +-------------------+ 137 | Public | 138 | Peering Function | 139 | or | 140 | Public | 141 |Federation Function| 142 +-------------------+ 143 | 144 ----- 145 +-----------+ / \ +-----------+ 146 |Enterprise | -- -- |Enterprise | 147 |Provider A |-----------/ \-----------|Provider B | 148 +-----------+ -- -- +-----------+ 149 / Public \ 150 | Internet | 151 \ (Layer 3) / 152 +-----------+ -- -- +-----------+ 153 |Service |-----------\ /-----------|Service | 154 |Provider C | -- -- |Provider D | 155 +-----------+ \_____/ +-----------+ 156 | Layer 3 Peering 157 | Point (out of scope) 158 ----- 159 +-----------+ / \ +-----------+ 160 |Enterprise | -- -- |Enterprise | 161 |Provider E |-----------/ \-----------|Provider F | 162 +-----------+ -- Service -- +-----------+ 163 / Provider \ 164 | Private | 165 \ Network / 166 +-----------+ -- (Layer 3) -- +-----------+ 167 |Service |-----------\ /-----------|Service | 168 |Provider G | -- -- |Provider H | 169 +-----------+ \____/ +-----------+ 170 | 171 +-------------------+ 172 | Private | 173 | Peering Function | 174 | or | 175 |Federation Function| 176 +-------------------+ 178 Figure 1: SPEERMINT Network Context 180 3. Procedures 182 This document assumes that a call from an end user in the initiating 183 peer goes through the following steps to establish a call to an end 184 user in the receiving peer: 186 1. The analysis of a target address. 188 a. If the target address represents an intra-VSP resource, 189 we go directly to step 4. 191 2. the discovery of the receiving peering point address, 193 3. the enforcement of authentication and other policy, 195 4. the discovery of end user address, 197 5. the routing of SIP messages, 199 6. the session establishment, 201 7. the transfer of media, 203 8. and the session termination. 205 4. Reference SPEERMINT Architecture 207 Figure 2 depicts the SPEERMINT architecture and logical functions 208 that form the peering between two SIP service providers I and R, 209 where I is the Initiating peer and R is the Receiving peer. 211 +------+ 212 | DNS, | 213 | Db, | 214 | etc | 215 ------- +------+ ------- 216 / \ | | / \ 217 | LF---+ +---LF | 218 | | | | 219 | PF----------PF | 220 | | | | 221 | SIP SF----------SF SIP | 222 | Service | | Service | 223 |Provider MF----------MF Provider| 224 | I | | R | 225 | | | | 226 | | | | 227 \ / \ / 228 ------- ------- 230 Figure 2: Reference SPEERMINT Architecture 232 The procedures presented in Chapter 3 are implemented by a set of 233 peering functions: 235 o Location Function (LF): Purpose is to develop call routing data 236 (CRD) by discovering the Signaling Function (SF), Policy Function 237 (PF), and end user's reachable host (IP address and port). 239 o Policy Function (PF): Purpose is to perform authentication and to 240 exchange policy parameters to be used by the SF. The data acquired 241 through the policy function can provide input to the LF, SF or MF 242 functions. Therefore the policy function can happen multiple times 243 (through multiple methods) during the procedures used to establish 244 a call. 246 o Signaling Function (SF): Purpose is to perform routing of SIP 247 messages, to optionally perform termination and re-initiation of 248 call, to optionally implement security and policies on SIP 249 messages, and to assist in discovery/exchange of parameters to be 250 used by the Media Function (MF). 252 o Media Function (MF): Purpose is to perform media related function 253 such as media transcoding and media security implementation 254 between two SIP providers. 256 The intention of defining these functions is to provide a framework 257 for design segmentation and allow each one to evolve separately. 259 5. Peer Function Examples 261 This section describes the peering functions in more detail and 262 provides some examples on the role they would play in a SIP call in a 263 Layer 5 peering scenario. 265 Some of the information in the chapter is taken from [14]. 267 5.1. The Location Function (LF) of an Initiating Provider 269 Purpose is to develop call routing data (CRD) [12] by discovering 270 the Signaling Function (SF), Policy Function (PF), and end user's 271 reachable host (IP address and host). The LF of an Initiating 272 provider analyzes target address and discovers the next hop 273 signaling function (SF) in a peering relationship using DNS, SIP 274 Redirect Server, or a functional equivalent database. 276 5.1.1. Target address analysis 278 When the initiating provider receives a request to communicate, the 279 initiating provider analyzes the target state data to determine 280 whether the call needs to be terminated internal or external to its 281 network. The analysis method is internal to the provider's policy; 282 thus, outside the scope of SPEERMINT. Note that the peer is free to 283 consult any manner of private data sources to make this 284 determination. 286 If the target address does not represent a resource inside the 287 initiating peer's administrative domain or federation of domains, the 288 initiating provider resolves the call routing data by using the 289 Location Function (LF). Examples of the LF are the functions of ENUM, 290 Routing Table, SIP DNS, and SIP Redirect Server. 292 If the request to communicate is for an im: or pres: URI type, the 293 initiating peer follows the procedures in [8]. If the highest 294 priority supported URI scheme is sip: or sips:, the initiating peer 295 skips to SIP DNS resolution in Section 5.1.5. Likewise, if the target 296 address is already a sip: or sips: URI in an external domain, the 297 initiating peer skips to SIP DNS resolution in Section 5.1.5. 299 If the target address corresponds to a specific E.164 address, the 300 peer may need to perform some form of number plan mapping according 301 to local policy. For example, in the United States, a dial string 302 beginning "011 44" could be converted to "+44", or in the United 303 Kingdom "00 1" could be converted to "+1". Once the peer has an 304 E.164 address, it can use ENUM. 306 5.1.2. User ENUM Lookup 308 If an external E.164 address is the target, the initiating peer 309 consults the public "User ENUM" rooted at e164.arpa, according to the 310 procedures described in RFC 3761. The peer MUST query for the 311 "E2U+sip" enumservice as described in RFC 3764 [11], but MAY check 312 for other enumservices. The initiating peer MAY consult a cache or 313 alternate representation of the ENUM data rather than actual DNS 314 queries. Also, the peer MAY skip actual DNS queries if the 315 initiating peer is sure that the target address country code is not 316 represented in e164.arpa. If a sip: or sips: URI is chosen the peer 317 skips to Section 5.1.5. 319 If an im: or pres: URI is chosen for based on an "E2U+im" [10] or 320 "E2U+pres" [9] enumserver, the peer follows the procedures for 321 resolving these URIs to URIs for specific protocols such a SIP or 322 XMPP as described in the previous section. 324 5.1.3. Carrier ENUM lookup 326 Next the initiating peer checks for a carrier-of-record in a carrier 327 ENUM domain according to the procedures described in [12]. As in the 328 previous step, the peer MAY consult a cache or alternate 329 representation of the ENUM data in lieu of actual DNS queries. The 330 peer first checks for records for the "E2U+sip" enumservice, then for 331 the "E2U+pstn" enumservice as defined in [21]. If a terminal record 332 is found with a sip: or sips: URI, the peer skips to Section 5.1.5, 333 otherwise the peer continues processing according to the next 334 section. 336 5.1.4. Routing Table 338 If there is no user ENUM records and the initiating peer cannot 339 discover the carrier-of-record or if the initiating peer cannot reach 340 the carrier-of-record via SIP peering, the initiating peer still 341 needs to deliver the call to the PSTN or reject the call. Note that 342 the initiating peer MAY still sends the call to another provider for 343 PSTN gateway termination by prior arrangement using a routing table. 344 If so, the initiating peer rewrites the Request-URI to address the 345 gateway resource in the target provider's domain and MAY forward the 346 request on to that provider using the procedures described in the 347 remainder of these steps. 349 5.1.5. SIP DNS Resolution 351 Once a sip: or sips: in an external domain is selected as the target, 352 the initiating peer uses the procedures described in [4] Section 4. 354 To summarize the RFC 3263 procedure: unless these are explicitly 355 encoded in the target URI, a transport is chosen using NAPTR records, 356 a port is chosen using SRV records, and an address is chosen using A 357 or AAAA records. Note that these are queries of records in the 358 global DNS. 360 It is worth mentioning that the PF can override the default RFC 3263 361 procedure. That may be based on learned routes (via SUBSCRIBE), or 362 federation announcements. 364 5.1.6. SIP Redirect Server 366 A SIP Redirect Server may help in resolving current address of a 367 mobile target address. 369 5.2. The Location Function (LF) of a Receiving Provider 371 5.2.1. Publish ENUM records 373 The receiving peer SHOULD participate by publishing "E2U+sip" and 374 "E2U+pstn" records with sip: or sips: URIs wherever a public carrier 375 ENUM root is available. This assumes that the receiving peer wants 376 to peer by default. Even when the receiving peer does not want to 377 accept traffic from specific initiating peers, it MAY still reject 378 requests on a case-by-case basis. 380 5.2.2. Publish SIP DNS records 382 To receive peer requests, the receiving peer MUST insure that it 383 publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records 384 in the global DNS that resolve an appropriate transport, port, and 385 address to a relevant SIP server. 387 5.3. Policy Function (PF) 389 The purpose of policy function is to perform authentication and to 390 exchange peering policy capabilities to be used by the signaling 391 function. The policy function can happen multiple times (through 392 multiple methods) during the procedures used to establish a call and 393 the data acquired as a result can provide input to the LF, SF or MF 394 functions. 396 Policy data can come through DNS NAPTR resolution as shown in [18] 397 and/or a SIP peering event package [22]. 399 The policy capabilities should be specified through well defined XML 400 schemas. These policies define the capabilities of each peer and its 401 devices used for peering. For example, the following capabilities 402 could be exchanged through the policy function: 404 o Adjacency (Next hop network attributes) 406 o If there are many adjacent proxies to use, the choice could be 407 based on: 409 . Location of the proxy 411 . Maximum number of calls per second (CPS) 413 . Maximum number of established calls 415 . Maximum allowed bandwidth (KBS) 417 o Path Discovery (Domains that are NOT adjacent) 419 o What are the paths to the destination domain that can: 421 . Guarantee quality 423 . Participate in Guarantee's for Trust 425 . Are these paths available? 427 o Adjacency and Path Congestion detection/avoidance 429 o Inflow Traffic Restriction (not call-by-call) 431 o For maintenance actions 433 o For congestion management 435 o How can a carrier prevent upstream networks from submitting 436 calls for certain destinations in overload 438 The authentication policy function can be implemented by TLS (as 439 described in (5.3.1), IPSec or any other method that meet the 440 security needs to a specific deployment. 442 Editor's Note: This section will be updated based on the progress on 443 the SPEERMINT policy document. 445 5.3.1. TLS 447 Once a transport, port, and address are found, the initiating peer 448 will open or find a reusable TLS connection to the peer. The 449 initiating provider should verify the server certificate which should 450 be rooted in a well-known certificate authority. The initiating 451 provider should be prepared to provide a TLS client certificate upon 452 request during the TLS handshake. The client certificate should 453 contain a DNS or URI choice type in the subject AltName which 454 corresponds to the domain asserted in the host production of the From 455 header URI. The certificate should be valid and rooted in a well- 456 known certificate authority. Note that the client certificate MAY 457 contain a list of entries in the subjectAltName, only one of which 458 has to match the domain in the From header URI. 460 When the receiving peer receives a TLS client hello, it responds with 461 its certificate. The receiving peer certificate SHOULD be valid and 462 rooted in a well-known certificate authority. The receiving peer 463 should request and verify the client certificate during the TLS 464 handshake. 466 5.3.2. IPSec 468 Editor's Note: will be described later. 470 5.3.3. Subscribe Notify 472 Policy function may also be optionally implemented by dynamic 473 subscribe, notify, and exchange of policy information and feature 474 information among providers [22]. 476 5.4. Signaling Function (SF) 478 The purpose of signaling function is to perform routing of SIP 479 messages, to optionally perform termination and re-initiation of a 480 call, to optionally implement security and policies on SIP messages, 481 and to assist in discovery/exchange of parameters to be used by the 482 Media Function (MF). 484 The routing of SIP messages are performed by SIP proxies. The 485 optional termination and re-initiation of calls are performed by 486 B2BUA. 488 Optionally, a SF may perform additional functions such as Session 489 Admission Control, SIP Denial of Service protection, SIP Topology 490 Hiding, SIP header normalization, and SIP security, privacy and 491 encryption. 493 The signaling function can also process SDP payloads for media 494 information such as media type, bandwidth, and type of codec; then, 495 communicate this information to the media function. Signaling 496 function may optionally communicate with network layer to pass Layer 497 3 related policies [10] 499 5.5. Media Function (MF) 501 Examples of the media function is to transform voice payload from one 502 coding (e.g., G.711) to another (e.g., EvRC), media relaying, media 503 security, privacy, and encryption. 505 Editor's Note: This section will be further updated. 507 6. Call Control and Media Control Deployment Options 509 The peering functions can either be deployed along the following two 510 dimensions depending upon how the signaling function and the media 511 function along with IP functions are implemented: 513 Composed or Decomposed: Addresses the question whether the media 514 paths must flow through the same physical and geographic nodes as the 515 call signaling, 517 Centralized or Distributed: Addresses the question whether the 518 logical and physical peering points are in one geographical location 519 or distributed to multiple physical locations on the service provider 520 network. 522 In a composed model, SF and MF functions are implemented in one 523 peering logical element. 525 Provider A Provider B 526 ---------- . . ---------- 527 / \ . . / \ 528 | | . _ . | | 529 | +----+ . / \_ . +----+ | 530 | | SF |<-----/ \------| SF | | 531 | +-+--+ . /Transit\ . | | | 532 | | | . / IP \ . | | | 533 | +-+--+ . \ Provider| . | | | 534 | | MF |<~~~~\(Option)|~~~~| MF | | 535 | +----+ . \ / . +----+ | 536 | | . \__ _/ . | | 537 \_________ / . . \________ _/ 538 ---------- ---------- 540 --- Signal (SIP) 541 ~~~ Bearer (RTP/IP) 542 ... Scope of peering 544 Figure 3: Decomposed v. Collapsed Peering 546 The advantage of a collapsed peering architecture is that one-element 547 solves all peering issues. Disadvantage examples of this architecture 548 are single point failure, bottle neck, and complex scalability. 550 In a decomposed model, SF and MF are implemented in separate peering 551 logical elements. Signaling functions are implemented in a proxy and 552 media functions are implemented in another logical element. The 553 scaling of signaling versus scaling of media may differ between 554 applications. Decomposing allows each to follow a separate migration 555 path. 557 This model allows the implementation of M:N model where one SF is 558 associated with multiple peering MF and one peering MF is associated 559 with multiple peering proxies. Generally, a vertical protocol 560 associates the relationship between a SF and a MF. This architecture 561 reduces the potential of single point failure. This architecture, 562 allows separation of the policy decision point and the policy 563 enforcement point. An example of disadvantages is the scaling 564 complexity because of the M:N relationship and latency due to the 565 vertical control messages between entities. 567 7. Security Considerations 569 In all cases, cryptographic-based security should be maintained as an 570 optional requirement between peering providers conditioned on the 571 presence or absence of underlying physical security of peer 572 connections, e.g. within the same secure physical building. 574 In order to maintain a consistent approach, unique and specialized 575 security requirements common for the majority of peering 576 relationships, should be standardized within the IETF. These 577 standardized methods may enable capabilities such as dynamic peering 578 relationships across publicly maintained interconnections. 580 TODO: Address RFC-3552 BCP items. 582 8. IANA Considerations 584 There are no IANA considerations at this time. 586 9. Acknowledgments 588 The working group thanks Sohel Khan for his initial architecture 589 draft that helped to initiate work on this draft. 591 A significant portion of this draft is taken from [14] with 592 permission from the author R. Mahy. The other important contributor 593 is Otmar Lendl. 595 Author's Addresses 597 Mike Hammer 598 Cisco Systems 599 13615 Dulles Technology Drive 600 Herndon, VA 20171 601 USA 602 Email: mhammer@cisco.com 604 Sohel Khan, Ph.D. 605 Technology Strategist 606 Sprint 607 6220 Sprint Parkway 608 Overland Park, KS 66251 609 U.S.A 610 Email: Sohel.Q.Khan@sprint.com 612 Daryl Malas 613 Level 3 Communications LLC 614 1025 Eldorado Blvd. 615 Broomfield, CO 80021 616 USA 617 EMail: daryl.malas@level3.com 619 Reinaldo Penno (Editor) 620 Juniper Networks 621 1194 N Mathilda Avenue 622 Sunnyvale, CA 623 USA 624 Email: rpenno@juniper.net 626 Adam Uzelac 627 Global Crossing 628 1120 Pittsford Victor Road 629 PITTSFORD, NY 14534 630 USA 631 Email: adam.uzelac@globalcrossing.com 633 10. References 635 10.1. Normative References 637 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 638 Levels", BCP 14, RFC 2119, March 1997. 640 [2] Mealling, M. and R. Daniel, "The Naming Authority Pointer 641 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 643 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 644 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 645 Session Initiation Protocol", RFC 3261, June 2002. 647 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 648 (SIP): Locating SIP Servers", RFC 3263, June 2002. 650 [5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 651 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 652 3546, June 2003. 654 [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 655 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 656 RFC 3550, July 2003. 658 [7] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 659 numbers with the Session Initiation Protocol (SIP)", RFC 3824, 660 June 2004. 662 [8] Peterson, J., "Address Resolution for Instant Messaging and 663 Presence",RFC 3861, August 2004. 665 [9] Peterson, J., "Telephone Number Mapping (ENUM) Service 666 Registration for Presence Services", RFC 3953, January 2005. 668 [10] ETSI TS 102 333: " Telecommunications and Internet converged 669 Services and Protocols for Advanced Networking (TISPAN); Gate 670 control protocol". 672 [11] Peterson, J., "enumservice registration for Session Initiation 673 Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. 675 10.2. Informative References 677 [12] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint- 678 terminology-04 (work in progress), May 2006. 680 [13] Mule, J-F., "SPEERMINT Requirements for SIP-based VoIP 681 Interconnection", draft-ietf-speermint-requirements-00.txt, 682 June 2006. 684 [14] Mahy, R., "A Minimalist Approach to Direct Peering", draft- 685 mahy-speermint-direct-peering-00.txt, June 19, 2006. 687 [15] Penno, R., et al., "SPEERMINT Routing Architecture Message 688 Flows", draft-ietf-speermint-flows-00.txt", August 2006. 690 [16] Lee, Y., "Session Peering Use Case for Cable", draft-lee- 691 speermint-use-case-cable-00.txt, June, 2006. 693 [17] Houri, A., et al., "RTC Provisioning Requirements", draft- 694 houri-speermint-rtc-provisioning-reqs-00.txt, June, 2006. 696 [18] Habler, M., et al., "A Federation based VOIP Peering 697 Architecture", draft-lendl-speermint-federations-03.txt, 698 September 2006. 700 [19] Mahy, R., "A Telephone Number Mapping (ENUM) Service 701 Registration for Instant Messaging (IM) Services", draft-ietf- 702 enum-im-service-00 (work in progress), March 2006. 704 [20] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in 705 the e164.arpa tree", draft-haberler-carrier-enum-02 (work in 706 progress), March 2006. 708 [21] Livingood, J. and R. Shockey, "IANA Registration for an 709 Enumservice Containing PSTN Signaling Information", draft-ietf- 710 enum-pstn-04 (work in progress), May 2006. 712 [22] Penno, R., Malas D., and Melampy, P., "A Session Initiation 713 Protocol (SIP) Event package for Peering", draft-penno-sipping- 714 peering-package-00 (work in progress), September 2006. 716 Intellectual Property Statement 718 The IETF takes no position regarding the validity or scope of any 719 Intellectual Property Rights or other rights that might be claimed to 720 pertain to the implementation or use of the technology described in 721 this document or the extent to which any license under such rights 722 might or might not be available; nor does it represent that it has 723 made any independent effort to identify any such rights. Information 724 on the procedures with respect to rights in RFC documents can be 725 found in BCP 78 and BCP 79. 727 Copies of IPR disclosures made to the IETF Secretariat and any 728 assurances of licenses to be made available, or the result of an 729 attempt made to obtain a general license or permission for the use of 730 such proprietary rights by implementers or users of this 731 specification can be obtained from the IETF on-line IPR repository at 732 http://www.ietf.org/ipr. 734 The IETF invites any interested party to bring to its attention any 735 copyrights, patents or patent applications, or other proprietary 736 rights that may cover technology that may be required to implement 737 this standard. Please address the information to the IETF at 738 ietf-ipr@ietf.org. 740 Disclaimer of Validity 742 This document and the information contained herein are provided on an 743 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 744 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 745 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 746 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 747 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 748 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 750 Copyright Statement 752 Copyright (C) The Internet Society (2006). 754 This document is subject to the rights, licenses and restrictions 755 contained in BCP 78, and except as set forth therein, the authors 756 retain all their rights. 758 Acknowledgment 760 Funding for the RFC Editor function is currently provided by the 761 Internet Society.