Network Working Group S. Khan Internet Draft Sprint Expires: November 2006 R. Penno Juniper Networks D. Malas Level 3 May 2, 2006 SPEERMINT Peering Architecture draft-khan-ip-serv-peer-arch-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 2, 2006. Abstract This document defines a SPEERMINT peering reference architecture, its functional components and peering interface functions. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. khan Expires November 2, 2006 [Page 1] Internet-Draft SPEERMINT Peering Architecture May 2006 Table of Contents 1. Introduction...................................................2 2. Peering Interface functions....................................4 2.1. Signaling Function........................................4 2.2. Peering Location Function.................................5 2.3. Media Function............................................5 2.4. QoS Function (QF).........................................6 2.5. Application Function......................................6 2.6. Operation and Management Function.........................6 3. Reference Peering Architecture.................................7 4. IP Layer Function..............................................7 5. Scaling of Functions...........................................8 5.1. Composed..................................................8 5.2. Decomposed................................................8 6. Security Considerations.......................................10 7. IANA Considerations...........................................10 8. Conclusions...................................................10 9. Acknowledgments...............................................10 10. References...................................................10 10.1. Normative References....................................10 10.2. Informative References..................................10 Author's Addresses...............................................11 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................12 Copyright Statement..............................................12 Acknowledgment...................................................12 1. Introduction The objective of this document is to define a reference peering architecture in the context of SPEERMINT. In this process, we define a peering reference architecture, its functional components, and peering interface functions from the perspective of a real-time application (Voice and Multimedia) IP Service provider network. This reference architecture applies to SIP-based voice and multimedia traffic only. This reference architecture does not apply to traditional Internet or Internet traffic such as HTTP. A real-time application (Voice and Multimedia) IP Service provider network contains functions of SIP/SIPPING/SIMPLE related RFCs in general and RFC3261 [2] in particular. Examples of these functions are SIP Proxies, SIP UAs, and B2BUAs. In addition, these IP Service providers' networks contain IP Routers, Application servers, and databases. To facilitate interface with the PSTN network, a Service khan Expires November 2, 2006 [Page 2] Internet-Draft SPEERMINT Peering Architecture May 2006 provider network contains Media Gateway Control Function (MGCF) and Media Gateway (MG). The network may also contain private ENUM and DNS. The Network Architecture of a real-time application (Voice and Multimedia) IP Service provider is shown below. /-------\ /------------------------------\ | | +----------+ | | +------+ | | | Peering | | +-----------+ |<--->| IP | | | | Location | | |Application| |<...>| phone| | | | Function |........... | Servers, | | +------+ | | +----------+.Peering . | Databases | | | | / \ .Interface. +-----------+ | | |-------------.Functions. | +--------+ | |*************........... +-----------+ |<-->|Wireless| | | | | SIP | |<..>| IP | | Peer | | +---------+ | Proxies | | |Network | | | | | Private | +-----------+ | +--------+ | | | | ENUM | | | | | +---------+ +-----------+ | | | | |SIP UAs | | | | | |B2BUAs | | | | | +-----------+ | | | | +----+| +----+ | | | +--------+ |MGCF||| | | | | | IP | +----+| | | | | | | Routers| +---+ | |PSTN| | | | +--------+ |MG | | | | | | | +---+ | +----+ | | | | | | | | \-------/ \------------------------------/ --- Signaling (SIP) *** Media (Coded Voice/Video/Data) Figure 1 Reference Peering Architecture A real-time application (Voice and Multimedia) IP Service provider interconnects with other real-time application (Voice and Multimedia) IP Service providers through a set of peering interface functions which are discussed next. khan Expires November 2, 2006 [Page 3] Internet-Draft SPEERMINT Peering Architecture May 2006 2. Peering Interface functions An IP Service peering interface can be divided into various planes: application, signaling, media, traffic engineering, and operation- management. This document defines the modules performing these interfaces as Application Function (AP), Signaling Function (SF), Peering Location Function (PL), Media Function (MF), QoS Function (QF), and Operation & Management Function (OF). Note that the security is associated with all these functions. .................... . +------+ . . . | SF | . . . +------+ . . . . . . +------+ . . . | PL | . S . . +------+ . . . . E . . +------+ . . . | MF | . C . . +------+ . . . . U . . +------+ . . . | QF | . R . . +------+ . . . . I . . +------+ . . . | OF | . T . . +------+ . . . . Y . . +------+ . . . | AF | . . . +------+ . . .................... Figure 2 Peering Interface Functions (PIF) 2.1. Signaling Function The SF performs Layer 5 peering functions i.e., SIP signaling and control functions at the interconnect interface. Examples of SF from SIP RFCs are SIP Proxy and SIP B2BUA. Other examples of SF include Session Admission Control (SAC), SIP Interoperability, SIP Denial of Service (DoS) protection, SIP Topology Hiding (THIG), and SIP security, privacy and encryption. khan Expires November 2, 2006 [Page 4] Internet-Draft SPEERMINT Peering Architecture May 2006 2.2. Peering Location Function The PL provides a mutual location servicing capability between two peers or among peers in a federation (a providers' group that has contractual agreements on various aspects of peering relationship such as common administrative policy, settlement, and terminating calls). The main function of the PL is to provide a mutually trusted registry database. Possible examples of a PL are mutually trusted DNS, ENUM, SIP Registration Server, SIP Redirect Server, or SIP proxy server in a federation. PL can also perform accounting for the federation by gathering call detailed record's (CDR). The PL may be implemented in a private network. The PL can be either owned by one provider, a third party, or a federation. The ownership decision of the PL is outside the scope of SPEERMINT. The SPEERMINT will develop technology and requirements associated with the PL. The following shows an example of PL architecture in a star topology. All four providers in a federation are fully meshed connected in IP (L3). However, they are either connected with each other in SIP (L5) through PL or uses PL as a SIP redirect/location server. +-------------+ +--------------+ | Provider A | | Provider B | +-------------+\ /+--------------+ \ / \ /SIP \ / \ / +------------------------ -+ | Peering Location Function| +--------------------------+ / \ / \ / \ / \ +-------------+ / \+--------------+ | Provider C |/ | Provider D | +-------------+ +--------------+ 2.3. Media Function Media represents a Layer 5. Encoded Voice or Video is a media and carried over RTP/IP. Here, IP is a Layer 3. khan Expires November 2, 2006 [Page 5] Internet-Draft SPEERMINT Peering Architecture May 2006 The MF may transform voice payload from one coding (e.g., G.711) to another (e.g., EvRC). Other Media Functions (MF) include media security, privacy and encryption. Playing announcement can be either a part of MF or AF. 2.4. QoS Function (QF) The QF performs QoS functions and its implementation is OPTIONAL unless government regulations mandate required implementation. Examples of QF are the marking of packets according to the peer's QoS policy. A separate IETF document would address SIP priority and QoS issues. SIP priority header mapping should adhere to the other standard body (e.g., 3GPP and ITU) recommendations with special attentions to the emergency services (ETS/WPS). The QF may also include negotiated standard telephony performance metrics such as Ineffective Attempts (IA) and Cut off Calls (CC) as specified in Telcordia GR-512-CORE, Post Dial Delay (PDD) specified in ITU-T E.721, Defects per Million (DPM) applied as specified by Six Sigma, and others. These specifications have provided recommendations of standard metrics, which could be adopted to provide consistency in peering QoS policies. Available routes via the peering relationship may change based on Least Cost Routing (LCR) policies or Busy Hour (BH) periods. This capability inherently provides QF capabilities between the peers. 2.5. Application Function An AF is a special function that contains bi-laterally disclosed information about the application servers and databases of each IP service provider. An example of this function is to allow a session to select a better suited application server from a set of application servers located inside both service providers' network. Another example of AF is number portability. An AF may be deployed along with PL in a star topology described in section 2.2. 2.6. Operation and Management Function O&M Function (OF) includes CALEA implementation; accounting, billing and operational data mediation. khan Expires November 2, 2006 [Page 6] Internet-Draft SPEERMINT Peering Architecture May 2006 Call Detail Record's (CDR's) MAY be collected from the peering Location Server (PL) to be utilized by the peering operators. Based on the application, the format should be an open standard for common consumption of billing systems. Operators may use this data for a number of reasons, including billing in the event the peering relationship becomes unilateral. In order to limit the potential for billing systems to impact the PL, a separate server should be created to maintain all records collected from a single interconnection to any number of PL's. 3. Reference Peering Architecture +-------+ +-------+ | IP | ------- ------- | IP | | phone | <------> / \ / \ <------>| phone | +-------+ | AF ...........AF | +-------+ | | +----+ | | | | | PL | | | | +----+ | | | IP SF...........SF IP | +--------+ | Service | | Service | +--------+ |Wireless| |Provider MF .........MF Provider| |Wireless| |Network | <----->| (VM) | | (VM) |<-----> |Network | +--------+ | A QF .........QF B | +--------+ +------+ | | | | +------+ | | <------->| OF .........OF <-------> | | | PSTN | | | | | | PSTN | | | <-------> \ / \ / <-------> | | +------+ SS7 ------- ------- SS7 +------+ Figure 3 Reference Peering Architecture 4. IP Layer Function IP Layer function includes the implementation of Dual Network Address Translation (NAT), IPv4 and IPv6 mapping, IPv6 aggregation, L3 rate shaping, bandwidth theft protection, VPN mediation, and L3 DoS/DDoS protection in addition to the implementation of BGP. The implementation of many of these functions is OPTIONAL. The IP Layer function is outside the scope of SPEERMINT at this time; thus, we do not include them in the SPEEMINT Peering Architecture. Note, that the IP Router is outside the IP peering function in Figure 1. khan Expires November 2, 2006 [Page 7] Internet-Draft SPEERMINT Peering Architecture May 2006 5. Scaling of Functions The peering functions can either be deployed composed, decomposed, or distributed fashion depending upon how the SF and the MF along with IP functions are implemented. 5.1. Composed In a composed mode, SF, and MF functions are implemented in one entity. Provider B --------- . . -------------------- / \ . . / \ +-------+ | | . . | +-----+ <--------->| IP | | | . . | |proxy| <.........>| phone | | | . . +----+ +-----+ | +-------+ | <---|--------------------| SF |---> | +--------+ | <........................| MF |...> <--------->|Wireless| | | . . +----+ +--------+ <.........>|Network | |Provider A | . _ /\__ . | |Database| | +--------+ | | . / \ / \ . +----+ +--------+ | | <---------\ Transit \----| SF |---> +--+ +------+ | <..........| IP |....| MF |...> <-|MG|---->| | | | . \Provider/ . +----+ +----+ +--+ | PSTN | | | . -------- . | |MGCF|<.. |....>| | \ / . . | +----+ | SS7 +------+ --------- . . \ --------------------/ --- Bearer (RTP/IP) ... Signal (SIP) Figure 4: Composed Peering Architecture The advantage of composed peering architecture is that one-device solves all peering issues. Disadvantage examples of this architecture are single point failure, bottle neck, and complex scalability. 5.2. Decomposed In this model, SF and MF are implemented in separate entities. Signaling functions are implemented in a proxy and media functions are implemented in another device. khan Expires November 2, 2006 [Page 8] Internet-Draft SPEERMINT Peering Architecture May 2006 Provider B --------- . ------------------ / \ . / \ +-------+ | | . | +----+ <---------->| IP | | | . | |Proxy| <.........>| phone | | | . +-----+ +----+ | +-------+ | <------------| SF |---> | +--------+ | | . +-----+ <---------->|Wireless| | | . +----------+ <..........>|Network | | <............| MF |..> | +--------+ | | . | | | |Provider A | . +----------+ | | | . | +---------+ | | | . | |Database | | | | . | +---------+ | | | . | +--+ +------+ | | . | <-|MG|----->| | | | . | +----+ +--+ | PSTN | | | . | |MGCF|<....|....>| | \ / . | +----+ | SS7 +------+ --------- . \ ------------------ / --- Bearer (RTP/IP) ... Signal (SIP) ............ . +------+ . . | SF | . Proxy . +------+ . | | | (Control protocol e.g. MGCP) | ............ . +------+ . . | MF | . . +------+ . ............ Figure 5: Decomposed Peering Architecture This model allows the implementation of M:N model where one SF is associated with multiple peering routers and one peering router is associated with multiple peering proxies. Generally, a vertical protocol such as MGCP associates the relationship between a peering proxy and a peering router. This architecture reduces the potential of single point failure. This architecture, allows separation of the policy decision point and the policy enforcement point. An example of disadvantages is the scaling complexity because of the M:N khan Expires November 2, 2006 [Page 9] Internet-Draft SPEERMINT Peering Architecture May 2006 relationship and latency due to the vertical control messages between entities. 6. Security Considerations In all cases, security should be maintained as an optional requirement between peering providers. In order to maintain a consistent approach, unique and specialized security requirements common for the majority of peering relationships, should be standardized within the IETF. These standardized methods may enable capabilities such as dynamic peering relationships across publicly maintained interconnections. 7. IANA Considerations There are no IANA considerations at this time. 8. Conclusions The proposed peering reference architecture breaks the peering interface in a set of well defined functions. Such arranged allows each one to the specified and evolved separately. 9. Acknowledgments TBD 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [2] Sohel Khan et al., "Conceptual Deployment Scenarios of Session/Border Control(S/BC) Functions", expired draft-sohel- sipping-s-bc-concept-arch-00.txt khan Expires November 2, 2006 [Page 10] Internet-Draft SPEERMINT Peering Architecture May 2006 Author's Addresses Sohel Khan, Ph.D. Technology Strategist Sprint 6220 Sprint Parkway Overland Park, KS 66251 U.S.A Email: Sohel.Q.Khan@sprint.com Reinaldo Penno Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA USA Email: rpenno@juniper.net Daryl Malas Level 3 Communications LLC 1025 Eldorado Blvd. Broomfield, CO 80021 USA EMail: daryl.malas@level3.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement khan Expires November 2, 2006 [Page 11] Internet-Draft SPEERMINT Peering Architecture May 2006 this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. khan Expires November 2, 2006 [Page 12]