Network Working Group R. Penno Internet Draft Juniper Networks Expires: December 2006 D. Malas Level 3 S. Khan Sprint A. Uzelac Global Crossing M. Hammer Cisco Systems June 17, 2006 SPEERMINT Peering Architecture draft-khan-ip-serv-peer-arch-03 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 November 2006. Abstract khan Expires December 17, 2006 [Page 1] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 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]. Table of Contents 1. Introduction...................................................2 2. Network Context................................................4 3. Reference Peering Architecture.................................4 4. Peering Interface Functions....................................5 4.1. Location Function (LF)....................................6 4.2. Operation Function (OF)...................................7 4.3. Signaling Function (SF)...................................7 4.4. Media Function (MF).......................................8 4.5. QoS Function (QF).........................................8 4.6. Application Function (AF).................................9 5. Call Control and Media Control Deployment Options..............9 6. Security Considerations.......................................10 7. IANA Considerations...........................................10 8. Conclusions...................................................10 9. Acknowledgments...............................................11 10. References...................................................11 10.1. Normative References....................................11 10.2. Informative References..................................11 Author's Addresses...............................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................13 Copyright Statement..............................................13 Acknowledgment...................................................13 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 mainly to SIP-based voice and multimedia traffic only and has not considered traditional Internet traffic such as HTTP. khan Expires December 17, 2006 [Page 2] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 IP Layer peering is outside the scope of SPEERMINT at this time; thus, we do not include them in the SPEEMINT Peering Architecture. Note that IP Routers are not shown in the subsequent figures so that the focus is on Layer 5 protocol aspects. +------------------+ | Public | | Peering Function | | Location Server | +------------------+ | ----- +-----------+ / \ +-----------+ |Enterprise | -- -- |Enterprise | |Provider A |-----------/ \-----------|Provider B | +-----------+ -- -- +-----------+ / Public \ | Internet | \ (Layer 3) / +-----------+ -- -- +-----------+ |Service |-----------\ /-----------|Service | |Provider C | -- -- |Provider D | +-----------+ \_____/ +-----------+ | Layer 3 Peering | Point (out of scope) ----- +-----------+ / \ +-----------+ |Enterprise | -- -- |Enterprise | |Provider E |-----------/ \-----------|Provider F | +-----------+ -- Service -- +-----------+ / Provider \ | Private | \ Internet / +-----------+ -- (Layer 3) -- +-----------+ |Service |-----------\ /-----------|Service | |Provider G | -- -- |Provider H | +-----------+ \____/ +-----------+ | +------------------+ | Private | | Peering Function | | or | |Federation Entity | +------------------+ Figure 1: Peering Network Context khan Expires December 17, 2006 [Page 3] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 2. Network Context Figure 1 shows an example network context. Two or more providers on either the public Internet or private Layer 3 networks may form a SIP (Layer 5) federation. The public or private peering location server function enables discovery of federations and all provider peering points. Subsequent exchanges with those provider peering points will enable discover of policy and additional signaling and media peering Note that Figure 1 allows for the following potential interconnect scenarios: o Enterprise to Enterprise across the public Internet o Enterprise to Service Provider across the public Internet o Service Provider to Service Provider across the public Internet o Enterprise to enterprise across a private internet o Enterprise to Service Provider across a private internet o Service Provider to Service Provider across a private internet Note also that the nature of the Service Provider is intentionally ambiguous, so it encompasses both VoIP SP and other Application SP. Federation Entity We define federation as a providers' group that has contractual agreements on various aspects of peering relationship such as common administrative policy, settlement, and terminating calls. The members of a federation may jointly use a set of entities such as location function, application servers, subscriber databases, SIP proxies , and/or platforms that synthesize various SIP and non-SIP based applications. Next Hop: A next hop may be a direct peer or a transit peer. 3. Reference Peering Architecture Figure 2 shows the functional elements that act as border functions for exchanging information across the peering interface. khan Expires December 17, 2006 [Page 4] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 +----+ | LF | ------- +----+ ------- / \ | | / \ | LF---+ +---LF | | | | | | OF-----------OF | | | | | | IP SF-----------SF IP | | Service | | Service | |Provider MF---------MF Provider| | X | | Y | | QF-----------QF | | | | | | AF-----------AF | | | | | \ / \ / ------- ------- Figure 2: Reference Peering Architecture Within the Layer-5 Service Provider's network there may be IP phones, Proxies, B2BUA, Interactive Voice Response (IVR), and other hosts that originate or terminate L5 signaling and L5 media paths. The Layer-5 SP may also operate interworking Gateways to the PTSN and Wireless networks. These internal elements and external elements are beyond the scope of the Layer-5 Peering point. 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. The network may also contain private ENUM and DNS. 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. 4. Peering Interface Functions An IP Service peering interface can be divided into various planes. This document proposes the following decomposition of functions: o Location Function (LF): Purpose is to enable discovery of the SF or OF peering point. (Section 4.1) khan Expires December 17, 2006 [Page 5] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 o Operation Function (OF): Purpose is to enable discovery and exchange of policy and parameters to be used in with the SF peering point. (Section 4.2) o Signaling Function (SF): Purpose is to enable the discovery of endpoints and assist in discovery and exchange of parameters to be used with the MF peering point. (Section 4.3) o Media Function (MF): Purpose is to enable the interconnection of media paths between endpoints. (Section 4.4) o QoS Function (QF): Purpose is to negotiate and reserve bandwidth resources, as well as police and provide measurements for media paths. (Section 4.5) o Application Function (AF): TBD (Section 4.5) Note that each of these functions must address security considerations. 4.1. Location Function (LF) The LF provides a way to discover the next hop signaling function (SF) in a peering relationship. (do we . This can be accomplished through mutually trusted DNS, ENUM, SIP Redirect Server or functionally future database. The function of the LF is to provide a trusted registry database for next hop in a peering relationship. The registry can be either internal or external to the federation if federation exists. It may take multiple queries to resolve the next hop. Possible examples of a LF are: o ENUM: o Input: E.164 o Output: SIP AoR of a next hop Signaling Function (SF) or OF. o DNS: o Input: Domain Name from the AoR of an end user o Output: SIP AoR of the next hop Signaling Function (SF) o Global Public Database (if hierarchical system exists): khan Expires December 17, 2006 [Page 6] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 o Input: Local Signaling Function address (local context). The domain name of an end user or the domain name of a destination service provider o Output: The next hop reachable address. o SIP Redirect Server o Input: E.164 address or domain Name from the AoR of an end user o Output: SIP AoR of the next hop Signaling Function (SF) Capability of ENUM resolves number portability, SIP mobility resolves session layer mobility, and IP mobility resolves micro-mobility. Thus, the LF does not address the following issues: o Number portability function o Mobility function 4.2. Operation Function (OF) Operational function is optional. Examples of O&M Function (OF) are: o Dynamic subscribe, notify, and exchange of policy information and feature information among providers (See SIPPING Policy document and Peering Policy document) o SLA data exchange o Accounting data exchange: Call Detail Record's (CDR's) MAY be collected 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 asymmetric (unbalanced traffic flow) or there is a Tier 1 to Tier 2 relationship. In order to limit the potential for billing systems to impact the OF, a separate server should be created to maintain all records collected from a single interconnection to any number of OF's. 4.3. Signaling Function (SF) 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. Tasks that the SF must (must?) perform are: khan Expires December 17, 2006 [Page 7] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 Session Admission Control (SAC): This is an optional feature. A provider may or may not implement SAC. Define SAC: TBD Note, in case a session is rejected because of the SAC implementation, the session rejecting provider Y needs to inform the originating provider X, the cause of rejection with appropriate SIP error message. The SPEERMINT routing architecture message flow document will describe these messages. SIP Denial of Service (DoS) protection: Providers will most likely implement DoS protection mechanism. Define DoS: TBD Note, in case sessions are rejected due to the DoS protection implementation, the session rejecting provider Y needs to inform the originating provider X ,the cause of rejection with appropriate SIP error messages. The SPEERMINT routing architecture message flow document will describe these messages. Note also that this feature implementation is optional since DoS issue needs to be dealt with the case by case basis. SIP Topology Hiding (THIG): This optional feature will hide internal layer 5 architecture of a service provider and its end users. SIP security, privacy and encryption: The SF may support Security functions to provide authentication, privacy (encryption) and message integrity functions. These functions may be provided by using IPSec or TLS. 4.4. Media Function (MF) Media is composed of encoded Voice or Video carried in RTP streams carried within Layer 3 IP streams. 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. 4.5. QoS Function (QF) The QF typically would be at the IP border between service providers and ensure that incoming and outgoing packets are QOS-marked correctly according to federation or peer policy. Its implementation is OPTIONAL unless government regulations mandate required implementation. Separate IETF documents address SIP priority and QoS issues. It is desirable that the various standards bodies (e.g., IETF, ITU, and 3GPP) converge on a compatible set of SIP priority header mappings khan Expires December 17, 2006 [Page 8] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 particularly with special attention to the emergency services (ETS/WPS). 4.6. Application Function (AF) TO DO: Example and use case 5. Call Control and Media Control Deployment Options The peering functions can either be deployed along the following two dimensions depending upon how the SF and the MF along with IP functions are implemented: Composed or Decomposed: Addresses the question whether the media paths must flow through the same physical and geographic nodes as the call signaling, Centralized or Distributed: Addresses the question whether the logical and physical peering points are in one geographical location or distributed to multiple physical locations on the service provider network. In a composed model, SF, and MF functions are implemented in one entity. Provider A Provider B ---------- . . ---------- / \ . . / \ | | . _ . | | | +----+ . / \_ . +----+ | | | SF |<-----/ \------| SF | | | e.g. +-+--+ . /Transit\ . | | | | MGCP-> | | . / IP \ . | | | | +-+--+ . \ Provider| . | | | | | MF |<~~~~\(Option)|~~~~| MF | | | +----+ . \ / . +----+ | | | . \__ _/ . | | \_________ / . . \________ _/ ---------- ---------- --- Signal (SIP) ~~~ Bearer (RTP/IP) ... Scope of peering Figure 3: Decomposed v. Composed Peering khan Expires December 17, 2006 [Page 9] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 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. In a decomposed model, SF and MF are implemented in separate entities. Signaling functions are implemented in a proxy and media functions are implemented in another device. The scaling of signaling versus scaling of media may differ between applications. Decomposing allows each to follow a separate migration path. 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 relationship and latency due to the vertical control messages between entities. 6. Security Considerations In all cases, cryptographic-based security should be maintained as an optional requirement between peering providers conditioned on the presence or absence of underlying physical security of peer connections, e.g. within the same secure physical building. 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. TODO: Address RFC-3552 BCP items. 7. IANA Considerations There are no IANA considerations at this time. 8. Conclusions The proposed peering reference architecture decomposes the peering interface into a set of well defined functions. Such an arrangement allows each function to the specified and evolved separately. khan Expires December 17, 2006 [Page 10] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 9. Acknowledgments Mark Evans from Sprint-Nextel Corporation helped to define security related signaling functions. 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] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", draft- ietf-sipping-session-policy-framework-00 (work in progress) [3] 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 December 17, 2006 [Page 11] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 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 Adam Uzelac Global Crossing 1120 Pittsford Victor Road PITTSFORD, NY 14534 USA Email: adam.uzelac@globalcrossing.com Mike Hammer Cisco Systems 13615 Dulles Technology Drive Herndon, VA 20171 USA Email: mhammer@cisco.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 khan Expires December 17, 2006 [Page 12] Internet-Draft draft-khan-ip-serv-peer-arch-03 June 2006 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 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 December 17, 2006 [Page 13]