--- 1/draft-ietf-speermint-requirements-10.txt 2011-03-11 13:15:28.000000000 +0100 +++ 2/draft-ietf-speermint-requirements-11.txt 2011-03-11 13:15:28.000000000 +0100 @@ -1,18 +1,18 @@ SPEERMINT Working Group J-F. Mule Internet-Draft CableLabs -Intended status: Informational October 25, 2010 -Expires: April 28, 2011 +Intended status: Informational March 11, 2011 +Expires: September 12, 2011 Requirements for SIP-based Session Peering - draft-ietf-speermint-requirements-10.txt + draft-ietf-speermint-requirements-11.txt Abstract This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. Status of this Memo @@ -22,25 +22,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 28, 2011. + This Internet-Draft will expire on September 12, 2011. Copyright Notice - Copyright (c) 2010 IETF Trust and the persons identified as the + Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -90,21 +90,21 @@ information about SIP session peering. It is expected that the reader is familiar with the reference architecture described in [I-D.ietf-speermint-architecture], use cases for voice ([I-D.ietf-speermint-voip-consolidated-usecases]) and instant messaging and presence ([RFC5344]). Peering at the session layer can be achieved on a bilateral basis (direct peering established directly between two SSPs), or on an indirect basis via a session intermediary (indirect peering via a third-party SSP that has a trust relationship with the SSPs) - see - the terminology document for more details. + the terminology document [RFC5486] for more details. This document first describes general requirements. The use cases are then analyzed in the spirit of extracting relevant protocol requirements that must be met to accomplish the use cases. These requirements are intended to be independent of the type of media exchanged such as Voice over IP (VoIP), video telephony, and instant messaging. Requirements specific to presence and instant messaging are defined in Section 4. It is not the goal of this document to mandate any particular use of @@ -117,54 +117,58 @@ a session peering policy, provided in an informative appendix. It should be considered as an example of the information SIP Service Providers may have to discuss or agree on to exchange SIP traffic. 2. Terminology 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 [RFC2119]. - This document also reuses the terminology defined in [RFC5486]. It - is assumed that the reader is familiar with the Session Description - Protocol (SDP) [RFC4566] and the Session Initiation Protocol (SIP) - [RFC3261]. Finally, when used with capital letters, the terms - 'Authentication Service' are to be understood as defined by SIP - Identity [RFC4474]. + This document also reuses the terminology defined in [RFC5486]. + + It is assumed that the reader is familiar with the Session + Description Protocol (SDP) [RFC4566] and the Session Initiation + Protocol (SIP) [RFC3261]. Finally, when used with capital letters, + the terms 'Authentication Service' are to be understood as defined by + SIP Identity [RFC4474]. 3. General Requirements The following sub-sections contain general requirements applicable to multiple use cases for multimedia session peering. 3.1. Scope The primary focus of this document is on the requirements applicable to the boundaries of Layer 5 SIP networks: SIP entities, Signaling path Border Elements (SBEs), and the associated protocol requirements for the look-up and location routing of the session establishment data. The requirements applicable to SIP User Agents or related to the provisioning of the session data are considered out of scope. SIP Service Providers have to reach an agreement on numerous points when establishing session peering relationships . This document highlights only certain aspects of a session peering - agreement, mostly the requirements relevant to protocols: the - declaration, advertisement and management of ingress and egress - border elements for session signaling and media, information related - to the Session Establishment Data (SED), and the security properties - that may be desirable for secure session exchanges. + agreement. It describes the requirements relevant to protocols in + four areas: the declaration, advertisement and management of ingress + and egress border elements for session signaling and media (section + Section 3.2), the information exchange related to the Session + Establishment Data (SED, section Section 3.3), specific requirements + for presence and instant message (section Section 4) and the security + properties that may be desirable to secure session exchanges (section + Section 5). Numerous other considerations of session peering arrangements are critical to reach a successful agreement but they are considered out of scope of this document. They include information about SIP protocol support (e.g. SIP extensions and field conventions), media - (e.g., type of media traffic to be exchanged, compatible media codecs + (e.g. type of media traffic to be exchanged, compatible media codecs and transport protocols, mechanisms to ensure differentiated quality of service for media), layer-3 IP connectivity between the Signaling and Data path Border Elements, accounting and traffic capacity control (e.g. the maximum number of SIP sessions at each ingress point, or the maximum number of concurrent IM or VoIP sessions). The informative Appendix A lists parameters that may be considered when discussing the technical parameters of SIP session peering. The purpose of this list is to capture the parameters that are considered outside the scope of the protocol requirements. @@ -188,22 +192,22 @@ o Requirement #1: Protocol mechanisms MUST be provided to enable a SIP Service Provider to communicate the ingress Signaling Path Border Elements of its service domain. Notes on solution space: The SBEs may be advertised to session peers using static mechanisms or they may be dynamically advertised. There is general agreement that [RFC3263] provides a solution for dynamically advertising ingress SBEs in most cases of Direct or - Indirect peering. We discussed the DNS-based solution space - further in Requirement #4 below, especially in cases where the DNS + Indirect peering. We discuss the DNS-based solution space further + in Requirement #4 below, especially in cases where the DNS response varies based on who sends the query (peer-dependent SBEs). o Requirement #2: Protocol mechanisms MUST be provided to enable a SIP Service Provider to communicate the egress SBEs of its service domain. Notes on motivations for this requirement: For the purposes of capacity planning, traffic engineering and call admission control, a SIP Service Provider may be asked where @@ -252,62 +256,63 @@ It is impractical to ask users to use different target URIs based upon their SIP service provider's desire to receive incoming session signaling at different ingress SBEs based upon the originator. The solution described in [RFC3263] and based on DNS to advertise SBEs is therefore under-specified for this requirement. Other DNS mechanisms have been used extensively in other areas of the Internet, in particular in Content Distribution Internetworking to make the DNS responses vary based on the originator of the DNS query (see [RFC3466], [RFC3568] and - [RFC3570]). The applicability of such solutions needs for session + [RFC3570]). The applicability of such solutions for session peering needs further analysis. Finally, other techniques such as Anycast services ([RFC4786]) may be employed at lower layers than Layer 5 to provide a solution to this requirement. For example, anycast nodes could be defined by SIP service providers to expose a common address for SBEs into DNS, allowing the resolution of the anycast node address to the appropriate peer-dependent service address based on the routing topology or other criteria gathered from the combined use of anycast and DNS techniques. Notes on variability of the SBE advertisements based on the media capabilities: Some SSPs may have some restrictions on the type of media traffic their SBEs can accept. For SIP sessions however, it is not possible to communicate those restrictions in advance of the session initiation: a SIP target may support voice-only media, voice and video, or voice and instant messaging communications. While the inability to find out whether a particular type of SIP - session can be terminated by a certain SBE can cause failed - session establishment attempts, there is consensus to not add a - new requirement in this document. These aspects are essentially - covered by SSPs when discussing traffic exchange policies and are - deemed out of scope of this document. + session can be terminated by a certain SBE can cause session + attempts to fail, there is consensus to not add a new requirement + in this document. These aspects are essentially covered by SSPs + when discussing traffic exchange policies and are deemed out of + scope of this document. In the use cases provided as part of direct and indirect peering scenarios, an SSP deals with multiple SIP entities and multiple SBEs in its own domain. There is often a many-to-many relationship between the SIP Proxies considered inside the trusted network boundary of the SSP and its Signaling path Border Elements at the network boundaries. It should be possible for an SSP to define which egress SBE a SIP entity must use based on a given peer destination. - For example, in the case of an indirect peering scenario (section 5. - of [I-D.ietf-speermint-voip-consolidated-usecases]), it should be + For example, in the case of a static direct peering scenario (Figure + 2 in section 5.2. of + [I-D.ietf-speermint-voip-consolidated-usecases]), it should be possible for the SIP proxy in the originating network (O-Proxy) to select the appropriate egress SBE (O-SBE) to reach the SIP target based on the information the proxy receives from the Lookup Function (O-LUF) and/or Location Routing Function (O-LRF) - message response labeled (2). Note that this example also applies to the case of - Direct Peering when a service provider has multiple service areas and - each service area involves multiple SIP Proxies and a few SBEs. + indirect peering when a service provider has multiple service areas + and each service area involves multiple SIP Proxies and a few SBEs. o Requirement #5: The mechanisms recommended for the Look-Up Function (LUF) and the Location Routing Functions (LRF) MUST be capable of returning both a target URI destination and a value providing the next SIP hop(s). Notes: solutions may exist depending on the choice of the protocol used between the Proxy and its LUF/LRF. The idea is for the O-Proxy to be provided with the next SIP hop and the equivalent of @@ -315,22 +320,22 @@ protocol for the LUF, the solution space is undefined. It is desirable for an SSP to be able to communicate how authentication of a peer's SBEs will occur (see the security requirements for more details). o Requirement #6: The mechanisms recommended for locating a peer's SBE MUST be able to convey how a peer should initiate secure session establishment. - Notes: some mechanisms exist. For example, the required protocol - use of SIP over TLS may be discovered via [RFC3263] and guidelines + Notes: some mechanisms exist. For example, the required use of + SIP over TLS may be discovered via [RFC3263] and guidelines concerning the use of the SIPS URI scheme in SIP have been documented in [RFC5630]. 3.3. Session Establishment Data The Session Establishment Data (SED) is defined in [RFC5486] as the data used to route a call to the next hop associated with the called domain's ingress point. The following paragraphs capture some general requirements on the SED data. @@ -451,31 +455,33 @@ The privacy sharing mechanism must be done with the express consent of the user whose privacy settings will be shared with the other community. Because of the privacy-sensitive information exchanged between SSPs, the protocols used for the exchange of presence information must follow the security recommendations defined in section 6 of [RFC3863]. Notes: see section 2.3 of [RFC5344]. o Requirement #13: Multiple Watchers - It should be possible to send a presence document with a list of - watchers on the other community that should receive the presence - document notification. This will enable sending less presence - document notifications between the communities while avoiding the - need to share privacy information of presentities from one - community to the other. + It should be possible for an SPP to associate a presence document + with a list of watchers in the peer SSP community so that the peer + watchers can receive the presence document notifications. This + will enable sending less presence document notifications between + the communities while avoiding the need to share privacy + information of presentities from one community to the other. The systems used to exchange presence documents between SSPs SHOULD allow a presence document to be delivered to one or more watchers. - Note: The privacy sharing mechanisms defined in Requirement #12 - also apply to this requirement. + Note: The presence document and the list of authorized watchers in + the peer SSP may be sent separately. Also, the privacy sharing + mechanisms defined in Requirement #12 also apply to this + requirement. o Requirement #14: Standard PIDF Documents and Mappings Early deployments of SIP-based presence and Instant Messaging gateways have been done in front of legacy proprietary systems that use different naming schemes or name values for the elements and properties defined in a Presence Information Data Format (PIDF) document ([RFC3863]). For example the value "Do Not Disturb" in one presence service may be mapped to "Busy" in another system for the status element. Beyond this example of status values, it is important to ensure that the meaning of the @@ -638,40 +644,37 @@ 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References - [I-D.ietf-pmol-sip-perf-metrics] - Malas, D. and A. Morton, "Basic Telephony SIP End-to-End - Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07 - (work in progress), September 2010. - [I-D.ietf-speermint-architecture] - Malas, D. and J. Livingood, "SPEERMINT Peering - Architecture", draft-ietf-speermint-architecture-12 (work - in progress), October 2010. + Malas, D. and J. Livingood, "Session PEERing for + Multimedia INTerconnect Architecture", + draft-ietf-speermint-architecture-19 (work in progress), + February 2011. [I-D.ietf-speermint-voip-consolidated-usecases] Uzelac, A. and Y. Lee, "VoIP SIP Peering Use Cases", draft-ietf-speermint-voip-consolidated-usecases-18 (work in progress), April 2010. [I-D.ietf-speermint-voipthreats] Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, - "SPEERMINT Security Threats and Suggested - Countermeasures", draft-ietf-speermint-voipthreats-05 - (work in progress), September 2010. + "Session Peering for Multimedia Interconnect (SPEERMINT) + Security Threats and Suggested Countermeasures", + draft-ietf-speermint-voipthreats-07 (work in progress), + January 2011. [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. @@ -786,20 +789,23 @@ Security (DTLS)", RFC 5763, May 2010. [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010. + [RFC6076] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End + Performance Metrics", RFC 6076, January 2011. + Appendix A. Policy Parameters for Session Peering This informative section lists various types of parameters that should be considered by implementers when deciding what configuration variables to expose to system administrators or management stations, as well as SSPs or federations of SSPs when discussing the technical part of a session peering policy. In the context of session peering, a policy can be defined as the set of parameters and other information needed by an SSP to exchange @@ -898,23 +904,23 @@ o Performance Metrics: Layer-5 performance metrics should be defined and shared between peers. The performance metrics apply directly to signaling or media; they may be used pro-actively to help avoid congestion, call quality issues or call signaling failures, and as part of monitoring techniques, they can be used to evaluate the performance of peering exchanges. Examples of SIP performance metrics include the maximum number of SIP transactions per second on per domain basis, Session Completion Rate (SCR), Session Establishment Rate (SER), etc. - Some SIP end-to-end performance metrics are defined in - [I-D.ietf-pmol-sip-perf-metrics]; a subset of these may be - applicable to session peering and interconnects. + Some SIP end-to-end performance metrics are defined in [RFC6076]; + a subset of these may be applicable to session peering and + interconnects. Some media-related metrics for monitoring VoIP calls have been defined in the VoIP Metrics Report Block, in Section 4.7 of [RFC3611]. o Security: An SSP should describe the security requirements that other peers must meet in order to terminate calls to its network. While such a list of security-related policy parameters often depends on the security models pre-agreed to by peers, it is expected that these parameters will be discoverable or signaled in the future to allow @@ -949,21 +955,21 @@ include requirements on the use of secure media transport protocols such as SRTP, along with some constraints on the minimum authentication/encryption options for use in SRTP. * Network-layer security parameters: this covers how IPsec security associated may be established, the IPsec key exchange mechanisms to be used and any keying materials, the lifetime of timed Security Associated if applicable, etc. * Transport-layer security parameters: this covers how TLS - connections should be established as described in Section + connections should be established as described in section Section 5. A.2. Summary of Parameters for Consideration in Session Peering Policies The following is a summary of the parameters mentioned in the previous section. They may be part of a session peering policy and appear with a level of requirement (mandatory, recommended, supported, ...).