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/