idnits 2.17.1 draft-ietf-speermint-architecture-00.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 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 786. ** 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 (August 8, 2006) is 6470 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: 'RFC2782' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC2915' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC3546' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC3611' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC3764' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC3824' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC3951' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC3952' is defined on line 707, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 728, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 745, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** Downref: Normative reference to an Informational RFC: RFC 3824 ** Downref: Normative reference to an Experimental RFC: RFC 3951 ** Downref: Normative reference to an Experimental RFC: RFC 3952 -- Possible downref: Non-RFC (?) normative reference: ref. 'GATE' == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-01 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-00 == Outdated reference: A later version (-01) exists of draft-ietf-sipping-session-policy-framework-00 == Outdated reference: A later version (-02) exists of draft-mahy-speermint-direct-peering-00 -- No information found for draft-ietf-speermint-message-flows - is the name correct? == Outdated reference: A later version (-01) exists of draft-lee-speermint-use-case-cable-00 == Outdated reference: A later version (-03) exists of draft-lendl-speermint-federations-01 == 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 Summary: 9 errors (**), 0 flaws (~~), 24 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R.Penno (Editor) 2 Internet Draft Juniper Networks 3 Expires: February 2007 August 8, 2006 5 SPEERMINT Peering Architecture 6 draft-ietf-speermint-architecture-00 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 a SPEERMINT peering reference 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 [RFC2119] 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.........................................6 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.....................................7 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.................................................10 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. Conclusions...................................................14 72 10. Acknowledgments..............................................14 73 Author's Addresses...............................................15 74 11. References...................................................15 75 11.1. Normative References....................................15 76 11.2. Informative References..................................17 77 Intellectual Property Statement..................................18 78 Disclaimer of Validity...........................................19 79 Copyright Statement..............................................19 80 Acknowledgment...................................................19 82 1. Introduction 84 The objective of this document is to define a reference peering 85 architecture in the context of Session PEERing for Multimedia 86 INTerconnect (SPEERMINT). In this process, we define a peering 87 reference architecture, its functional components, and peering 88 interface functions from the perspective of a real-time 89 communications (Voice and Multimedia) IP Service provider network. 91 This reference architecture allows the interconnection of two service 92 providers in layer 5 peering as defined in the SPEERMINT Requirements 93 [2] and Terminology [1] documents for the purpose SIP-based voice and 94 multimedia traffic. 96 IP Layer peering is outside the scope of SPEERMINT at this time; 97 thus, we do not include them in the SPEEMINT Peering Architecture. 98 Note that IP Routers are not shown in the subsequent figures so that 99 the focus is on Layer 5 protocol aspects. 101 This document uses terminology defined in the SPEERMINT Terminology 102 document [1]. 104 2. Network Context 106 Figure 1 shows an example network context. Two SIP providers can form 107 a Layer 5 peer over either the public Internet or private Layer 3 108 networks. In addition, two or more providers may form a SIP (Layer 5) 109 federation [1][9] on either the public Internet or private Layer 3 110 networks. This document does not make any assumption whether the SIP 111 providers directly peer to each other or through Layer 3 transit 112 network as per use case of [7]. 114 Note that Figure 1 allows for the following potential SPEERMINT 115 peering scenarios: 117 o Enterprise to Enterprise across the public Internet 119 o Enterprise to Service Provider across the public Internet 121 o Service Provider to Service Provider across the public Internet 123 o Enterprise to enterprise across a private Layer 3 network 125 o Enterprise to Service Provider across a private Layer 3 network 127 o Service Provider to Service Provider across a private Layer 3 128 network 130 The members of a federation may jointly use a set of functions such 131 as location peering function, application function, subscriber 132 database function, SIP proxies, and/or functions that synthesize 133 various SIP and non-SIP based applications. Similarly, two providers 134 may jointly use a set of peering functions. The federation functions 135 or the peering functions can be either public or private. 137 +------------------+ 138 | Public | 139 | Peering Function | 140 | or | 141 | Public | 142 |Federation Function| 143 +------------------+ 144 | 145 ----- 146 +-----------+ / \ +-----------+ 147 |Enterprise | -- -- |Enterprise | 148 |Provider A |-----------/ \-----------|Provider B | 149 +-----------+ -- -- +-----------+ 150 / Public \ 151 | Internet | 152 \ (Layer 3) / 153 +-----------+ -- -- +-----------+ 154 |Service |-----------\ /-----------|Service | 155 |Provider C | -- -- |Provider D | 156 +-----------+ \_____/ +-----------+ 157 | Layer 3 Peering 158 | Point (out of scope) 159 ----- 160 +-----------+ / \ +-----------+ 161 |Enterprise | -- -- |Enterprise | 162 |Provider E |-----------/ \-----------|Provider F | 163 +-----------+ -- Service -- +-----------+ 164 / Provider \ 165 | Private | 166 \ Network / 167 +-----------+ -- (Layer 3) -- +-----------+ 168 |Service |-----------\ /-----------|Service | 169 |Provider G | -- -- |Provider H | 170 +-----------+ \____/ +-----------+ 171 | 172 +------------------+ 173 | Private | 174 | Peering Function | 175 | or | 176 |Federation Function| 177 +------------------+ 179 Figure 1: SPEERMINT Network Context 181 3. Procedures 183 This document assumes that a call from an end user in the initiating 184 peer goes through the following steps to establish a call to an end 185 user in the receiving peer: 187 . the analysis of a target address, 189 . the discovery of the receiving peering point 190 address, 192 . the enforcement of authentication and other policy, 194 . the discovery of end user address, 196 . the routing of SIP messages, 198 . the session establishment, 200 . the transfer of media, 202 . and the session termination. 204 4. Reference SPEERMINT Architecture 206 Figure 2 depicts the SPEERMINT reference architecture and logical 207 functions that form the peering between two SIP service providers I 208 and R, where I is the Initiating peer and R is the Receiving peer. 210 +----+ 211 | LF | 212 ------- +----+ ------- 213 / \ | | / \ 214 | LF---+ +---LF | 215 | | | | 216 | PF-----------PF | 217 | | | | 218 | SIP SF-----------SF SIP | 219 | Service | | Service | 220 |Provider MF---------MF Provider| 221 | I | | R | 222 | | | | 223 | | | | 224 \ / \ / 225 ------- ------- 227 Figure 2: Reference SPEERMINT Architecture 229 The procedures presented in Chapter 3 are implemented by a set of 230 peering functions: 232 o Location Function (LF): Purpose is to develop call routing data 233 (CRD) by discovering the Signaling Function (SF), Policy Function 234 (PF), and end user's reachable host (IP address and port). 236 o Policy Function (PF): Purpose is to perform authentication and to 237 exchange policy parameters to be used by the SF. 239 o Signaling Function (SF): Purpose is to perform routing of SIP 240 messages, to optionally perform termination and re-initiation of 241 call, to optionally implement security and policies on SIP 242 messages, and to assist in discovery/exchange of parameters to be 243 used by the Media Function (MF). 245 o Media Function (MF): Purpose is to perform media related function 246 such as media transcoding and media security implementation 247 between two SIP providers. 249 The intention of defining these functions is to provide a framework 250 for design segmentation and allow each one to evolve separately. 252 5. Peer Function Examples 254 This section describes the peering functions in more detail and 255 provides some examples on the role they would play in a SIP call in a 256 Layer 5 peering scenario. 258 Some of the information in the chapter is taken from [4]. 260 5.1. The Location Function (LF) of an Initiating Provider 262 Purpose is to develop call routing data (CRD) [1] by discovering the 263 Signaling Function (SF), Policy Function (PF), and end user's 264 reachable host (IP address and host). The LF of an Initiating 265 provider analyzes target address and discovers the next hop 266 signaling function (SF) in a peering relationship using DNS, SIP 267 Redirect Server, or a functional equivalent database. 269 5.1.1. Target address analysis 271 When the initiating provider receives a request to communicate, the 272 initiating provider analyzes the target state data to determine 273 whether the call needs to be terminated internal or external to its 274 network. The analysis method is internal to the provider's policy; 275 thus, outside the scope of SPEERMINT. Note that the peer is free to 276 consult any manner of private data sources to make this 277 determination. 279 If the target address does not represent a resource inside the 280 initiating peer's administrative domain or federation of domains, the 281 initiating provider resolves the call routing data by using the 282 Location Function (LF). Examples of the LF are the functions of ENUM, 283 Routing Table, SIP DNS, and SIP Redirect Server. 285 If the request to communicate is for an im: or pres: URI type, the 286 initiating peer follows the procedures in [RFC3861]. If the highest 287 priority supported URI scheme is sip: or sips:, the initiating peer 288 skips to SIP DNS resolution in Section 5.1.5. Likewise, if the target 289 address is already a sip: or sips: URI in an external domain, the 290 initiating peer skips to SIP DNS resolution in Section 5.1.5.5.1.5. 292 If the target address corresponds to a specific E.164 address, the 293 peer may need to perform some form of number plan mapping according 294 to local policy. For example, in the United States, a dial string 295 beginning "011 44" could be converted to "+44", or in the United 296 Kingdom "00 1" could be converted to "+1". Once the peer has an 297 E.164 address, it can use ENUM. 299 5.1.2. User ENUM Lookup 301 If an external E.164 address is the target, the initiating peer 302 consults the public "User ENUM" rooted at e164.arpa, according to the 303 procedures described in RFC 3761. The peer MUST query for the 304 "E2U+sip" enumservice as described in RFC 3674 [11], but MAY check 305 for other enumservices. The initiating peer MAY consult a cache or 306 alternate representation of the ENUM data rather than actual DNS 307 queries. Also, the peer MAY skip actual DNS queries if the 308 initiating peer is sure that the target address country code is not 309 represented in e164.arpa. If a sip: or sips: URI is chosen the peer 310 skips to Section 5.1.5. 312 If an im: or pres: URI is chosen for based on an "E2U+im" [10] or 313 "E2U+pres" [RFC3953] enumserver, the peer follows the procedures for 314 resolving these URIs to URIs for specific protocols such a SIP or 315 XMPP as described in the previous section. 317 5.1.3. Carrier ENUM lookup 319 Next the initiating peer checks for a carrier-of-record in a carrier 320 ENUM domain according to the procedures described in [11]. As in the 321 previous step, the peer MAY consult a cache or alternate 322 representation of the ENUM data in lieu of actual DNS queries. The 323 peer first checks for records for the "E2U+sip" enumservice, then for 324 the "E2U+pstn" enumservice as defined in [12]. If a terminal record 325 is found with a sip: or sips: URI, the peer skips to Section 5.1.5, 326 otherwise the peer continues processing according to the next 327 section. 329 5.1.4. Routing Table 331 If there is no user ENUM records and the initiating peer cannot 332 discover the carrier-of-record or if the initiating peer cannot reach 333 the carrier-of-record via SIP peering, the initiating peer still 334 needs to deliver the call to the PSTN or reject the call. Note that 335 the initiating peer MAY still sends the call to another provider for 336 PSTN gateway termination by prior arrangement using a routing table. 337 If so, the initiating peer rewrites the Request-URI to address the 338 gateway resource in the target provider's domain and MAY forward the 339 request on to that provider using the procedures described in the 340 remainder of these steps. 342 5.1.5. SIP DNS Resolution 344 Once a sip: or sips: in an external domain is selected as the target, 345 the initiating peer uses the procedures described in [RFC3263] 346 Section 4. To summarize the RFC 3263 procedure: unless these are 347 explicitly encoded in the target URI, a transport is chosen using 348 NAPTR records, a port is chosen using SRV records, and an address is 349 chosen using A or AAAA records. Note that these are queries of 350 records in the global DNS. 352 5.1.6. SIP Redirect Server 354 A SIP Redirect Server may help in resolving current address of a 355 mobile target address. 357 5.2. The Location Function (LF) of a Receiving Provider 359 5.2.1. Publish ENUM records 361 The receiving peer SHOULD participate by publishing "E2U+sip" and 362 "E2U+pstn" records with sip: or sips: URIs wherever a public carrier 363 ENUM root is available. This assumes that the receiving peer wants 364 to peer by default. Even when the receiving peer does not want to 365 accept traffic from specific initiating peers, it MAY still reject 366 requests on a case-by-case basis. 368 5.2.2. Publish SIP DNS records 370 To receive peer requests, the receiving peer MUST insure that it 371 publishes appropriate NAPTR, SRV, and address (A and/or AAAA) records 372 in the global DNS that resolve an appropriate transport, port, and 373 address to a relevant SIP server. 375 5.3. Policy Function (PF) 377 Policy function is optional. The purpose of policy function is to 378 perform authentication and to exchange peering policy capabilities to 379 be used by the signaling function. 381 The policy capabilities should be specified through well defined XML 382 schemas. These policies define the capabilities of each peer and its 383 devices used for peering. For example, the following capabilities 384 could be exchanged through the policy function: 386 o Adjacency (Next hop network attributes) 388 o If there are many adjacent proxies to use, the choice could be 389 based on: 391 . Location of the proxy 393 . Maximum number of calls per second (CPS) 395 . Maximum number of established calls 397 . Maximum allowed bandwidth (KBS) 399 o Path Discovery (Domains that are NOT adjacent) 401 o What are the paths to the destination domain that can: 403 . Guarantee quality 405 . Participate in Guarantee's for Trust 407 . Are these paths available? 409 o Adjacency and Path Congestion detection/avoidance 411 o Inflow Traffic Restriction (not call-by-call) 413 o For maintenance actions 415 o For congestion management 417 o How can a carrier prevent upstream networks from submitting 418 calls for certain destinations in overload 420 The Policy function can be implemented by method such as described in 421 [6] as subscribe-notify. 423 The authentication policy function can be implemented by TLS (as 424 described in (5.3.1), IPSec or any other method that meet the 425 security needs to a specific deployment. 427 Editor's Note: This section will be updated based on the progress on 428 the SPEERMINT policy document. 430 5.3.1. TLS 432 Once a transport, port, and address are found, the initiating peer 433 will open or find a reusable TLS connection to the peer. The 434 initiating provider should verify the server certificate which should 435 be rooted in a well-known certificate authority. The initiating 436 provider should be prepared to provide a TLS client certificate upon 437 request during the TLS handshake. The client certificate should 438 contain a DNS or URI choice type in the subject AltName which 439 corresponds to the domain asserted in the host production of the From 440 header URI. The certificate should be valid and rooted in a well- 441 known certificate authority. Note that the client certificate MAY 442 contain a list of entries in the subjectAltName, only one of which 443 has to match the domain in the From header URI. 445 When the receiving peer receives a TLS client hello, it responds with 446 its certificate. The receiving peer certificate SHOULD be valid and 447 rooted in a well-known certificate authority. The receiving peer 448 should request and verify the client certificate during the TLS 449 handshake. 451 5.3.2. IPSec 453 Editor's Note: will be described later. 455 5.3.3. Subscribe Notify 457 Policy function may also be optionally implemented by dynamic 458 subscribe, notify, and exchange of policy information and feature 459 information among providers. 461 5.4. Signaling Function (SF) 463 The purpose of signaling function is to perform routing of SIP 464 messages, to optionally perform termination and re-initiation of a 465 call, to optionally implement security and policies on SIP messages, 466 and to assist in discovery/exchange of parameters to be used by the 467 Media Function (MF). 469 The routing of SIP messages are performed by SIP proxies. The 470 optional termination and re-initiation of calls are performed by 471 B2BUA. 473 Optionally, a SF may perform additional functions such as Session 474 Admission Control, SIP Denial of Service protection, SIP Topology 475 Hiding, SIP header normalization, and SIP security, privacy and 476 encryption. 478 The signaling function can also process SDP payloads for media 479 information such as media type, bandwidth, and type of codec; then, 480 communicate this information to the media function. Signaling 481 function may optionally communicate with network layer to pass Layer 482 3 related policies [GATE] 484 Signaling Function supports the following RFCs as per SPEERMINT 485 Requirement document [2]: 487 o SF MUST support the core SIP RFCs defined in SIP Hitchhikers 488 Guide [5]. 490 o SF MUST support SDP related RFCs: the Session 491 Description Protocol (SDP) [RFC2327], and the Offer/Answer 492 mechanism with SDP [RFC3264]. 494 o SF SHOULD support: Reliability of Provisional 495 Responses in SIP - PRACK [RFC3262], the SIP UPDATE method (for 496 e.g. for codec changes during a session) [RFC3311], the Reason 497 header field [RFC3326]. 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. Composed Peering 546 The advantage of composed 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. Conclusions 588 The proposed peering reference architecture decomposes the peering 589 interface into a set of well defined functions. Such an arrangement 590 allows each function to the specified and evolved separately. 592 10. Acknowledgments 594 The working group thanks Sohel Khan for his initial architecture 595 draft that helped to initiate work on this draft. 597 A significant portion of this draft is taken from [4] with permission 598 from the author R. Mahy. The other important contributor is Otmar 599 Lendl. 601 Author's Addresses 603 Mike Hammer 604 Cisco Systems 605 13615 Dulles Technology Drive 606 Herndon, VA 20171 607 USA 608 Email: mhammer@cisco.com 610 Sohel Khan, Ph.D. 611 Technology Strategist 612 Sprint 613 6220 Sprint Parkway 614 Overland Park, KS 66251 615 U.S.A 616 Email: Sohel.Q.Khan@sprint.com 618 Daryl Malas 619 Level 3 Communications LLC 620 1025 Eldorado Blvd. 621 Broomfield, CO 80021 622 USA 623 EMail: daryl.malas@level3.com 625 Reinaldo Penno (Editor) 626 Juniper Networks 627 1194 N Mathilda Avenue 628 Sunnyvale, CA 629 USA 630 Email: rpenno@juniper.net 632 Adam Uzelac 633 Global Crossing 634 1120 Pittsford Victor Road 635 PITTSFORD, NY 14534 636 USA 637 Email: adam.uzelac@globalcrossing.com 639 11. References 641 11.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 647 Protocol", RFC 2327, April 1998. 649 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 650 specifying the location of services (DNS SRV)", RFC 2782, 651 February 2000. 653 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 654 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 656 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 657 A., Peterson, J., Sparks, R., Handley, M., and E. 658 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 659 June 2002. 661 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 662 Provisional Responses in Session Initiation Protocol 663 (SIP)", RFC 3262, June 2002. 665 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 666 Protocol (SIP): Locating SIP Servers", RFC 3263, 667 June 2002. 669 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 670 with Session Description Protocol (SDP)", RFC 3264, 671 June 2002. 673 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 674 UPDATE Method", RFC 3311, October 2002. 676 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 677 Header Field for the Session Initiation Protocol (SIP)", 678 RFC 3326, December 2002. 680 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 681 and T. Wright, "Transport Layer Security (TLS) 682 Extensions", RFC 3546, June 2003. 684 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 685 Jacobson, "RTP: A Transport Protocol for Real-Time 686 Applications", STD 64, RFC 3550, July 2003. 688 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 689 Protocol Extended Reports (RTCP XR)", RFC 3611, 690 November 2003. 692 [RFC3764] Peterson, J., "enumservice registration for Session 693 Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, 694 April 2004. 696 [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using 697 E.164 numbers with the Session Initiation Protocol (SIP)", 698 RFC 3824, June 2004. 700 [RFC3861] Peterson, J., ''Address Resolution for Instant Messaging 701 and Presence'',RFC 3861, August 2004. 703 [RFC3951] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, 704 W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", 705 RFC 3951, December 2004. 707 [RFC3952] Duric, A. and S. Andersen, "Real-time Transport Protocol 708 (RTP) Payload Format for internet Low Bit Rate Codec 709 (iLBC) Speech", RFC 3952, December 2004. 711 [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service 712 Registration for Presence Services", RFC 3953, January 713 2005. 715 [GATE] ETSI TS 102 333: " Telecommunications and Internet 716 converged Services and Protocols for Advanced Networking 717 (TISPAN); Gate control protocol". 719 11.2. Informative References 721 [1] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint- 722 terminology-01 (work in progress), May 2006. 724 [2] Mule, J-F., ''SPEERMINT Requirements for SIP-based VoIP 725 Interconnection'', draft-ietf-speermint-requirements-00.txt, 726 June 2006. 728 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for 729 Session Initiation Protocol (SIP) Session Policies", draft- 730 ietf-sipping-session-policy-framework-00 (work in progress) 732 [4] Mahy, R., ''A Minimalist Approach to Direct Peering'', draft- 733 mahy-speermint-direct-peering-00.txt, June 19, 2006. 735 [5] Rosenberg, J., "A Hitchhikers Guide to the Session Initiation 736 Protocol (SIP)", February 2006. 738 [6] Penno, R., et al., ''SPEERMINT Routing Architecture Message 739 Flows'', draft-ietf-speermint-message-flows-00.txt'', August 740 2006. 742 [7] Lee, Y., ''Session Peering Use Case for Cable'', draft-lee- 743 speermint-use-case-cable-00.txt, June, 2006. 745 [8] Houri, A., et al., ''RTC Provisioning Requirements'', draft- 746 houri-speermint-rtc-provisioning-reqs-00.txt, June, 2006. 748 [9] Habler, M., et al., ''A Federation based VOIP Peering 749 Architecture'', draft-lendl-speermint-federations-01.txt, June 750 2006. 752 [10] Mahy, R., "A Telephone Number Mapping (ENUM) Service 753 Registration for Instant Messaging (IM) Services", draft-ietf- 754 enum-im-service-00 (work in progress), March 2006. 756 [11] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in 757 the e164.arpa tree", draft-haberler-carrier-enum-02 (work in 758 progress), March 2006. 760 [12] Livingood, J. and R. Shockey, "IANA Registration for an 761 Enumservice Containing PSTN Signaling Information", draft-ietf- 762 enum-pstn-04 (work in progress), May 2006. 764 Intellectual Property Statement 766 The IETF takes no position regarding the validity or scope of any 767 Intellectual Property Rights or other rights that might be claimed to 768 pertain to the implementation or use of the technology described in 769 this document or the extent to which any license under such rights 770 might or might not be available; nor does it represent that it has 771 made any independent effort to identify any such rights. Information 772 on the procedures with respect to rights in RFC documents can be 773 found in BCP 78 and BCP 79. 775 Copies of IPR disclosures made to the IETF Secretariat and any 776 assurances of licenses to be made available, or the result of an 777 attempt made to obtain a general license or permission for the use of 778 such proprietary rights by implementers or users of this 779 specification can be obtained from the IETF on-line IPR repository at 780 http://www.ietf.org/ipr. 782 The IETF invites any interested party to bring to its attention any 783 copyrights, patents or patent applications, or other proprietary 784 rights that may cover technology that may be required to implement 785 this standard. Please address the information to the IETF at 786 ietf-ipr@ietf.org. 788 Disclaimer of Validity 790 This document and the information contained herein are provided on an 791 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 792 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 793 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 794 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 795 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 798 Copyright Statement 800 Copyright (C) The Internet Society (2006). 802 This document is subject to the rights, licenses and restrictions 803 contained in BCP 78, and except as set forth therein, the authors 804 retain all their rights. 806 Acknowledgment 808 Funding for the RFC Editor function is currently provided by the 809 Internet Society.