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