draft-ietf-speermint-architecture-13.txt   draft-ietf-speermint-architecture-14.txt 
SPEERMINT D. Malas, Ed. SPEERMINT D. Malas, Ed.
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Informational J. Livingood, Ed. Intended status: Informational J. Livingood, Ed.
Expires: April 28, 2011 Comcast Expires: May 12, 2011 Comcast
October 25, 2010 November 8, 2010
SPEERMINT Peering Architecture SPEERMINT Peering Architecture
draft-ietf-speermint-architecture-13 draft-ietf-speermint-architecture-14
Abstract Abstract
This document defines a peering architecture for the Session This document defines a peering architecture for the Session
Initiation Protocol (SIP) [RFC3261], it's functional components and Initiation Protocol (SIP) [RFC3261], it's functional components and
interfaces. It also describes the components and the steps necessary interfaces. It also describes the components and the steps necessary
to establish a session between two SIP Service Provider (SSP) peering to establish a session between two SIP Service Provider (SSP) peering
domains. domains.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 3 2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 4
3. Procedures of Inter-Domain SSP Session Establishment . . . . . 4 3. Procedures of Inter-Domain SSP Session Establishment . . . . . 5
4. Relationships Between Functions/Elements . . . . . . . . . . . 5 4. Relationships Between Functions/Elements . . . . . . . . . . . 6
5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 5 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 6
5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 5 5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 6
5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 6 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 7
5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 6 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 7
5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 6 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 7
5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 7 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 8
5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 7 5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 8
5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 7 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 8
5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 8 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 9
5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 8 5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 9
5.1.3.1. Establishing a Trusted Relationship . . . . . . . 8 5.1.3.1. Establishing a Trusted Relationship . . . . . . . 9
5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 8 5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 8 5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 9
5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 9 5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 10
5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 9 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 10
5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 9 5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 10
5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 9 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 10
6. Address Space Considerations . . . . . . . . . . . . . . . . . 10 6. Address Space Considerations . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document defines a reference peering architecture for the This document defines a reference peering architecture for the
Session Initiation Protocol (SIP)[RFC3261], it's functional Session Initiation Protocol (SIP)[RFC3261], it's functional
components and interfaces, in the context of session peering for components and interfaces, in the context of session peering for
multimedia interconnects. In this process, we define the peering multimedia interconnects. In this process, we define the peering
reference architecture, its functional components, and peering reference architecture, its functional components, and peering
interface functions from the perspective of a SIP Service providers interface functions from the perspective of a SIP Service providers
[RFC5486] network. Thus, it also describes the components and the [RFC5486] network. Thus, it also describes the components and the
skipping to change at page 6, line 51 skipping to change at page 7, line 51
beginning "011 44" could be converted to "+44", or in the United beginning "011 44" could be converted to "+44", or in the United
Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164 Kingdom "00 1" could be converted to "+1". Once the SSP has an E.164
address, it can use ENUM. address, it can use ENUM.
5.1.1.2. ENUM Lookup 5.1.1.2. ENUM Lookup
If an external E.164 address is the target, the originating (or If an external E.164 address is the target, the originating (or
indirect) SSP consults the public "User ENUM" rooted at e164.arpa, indirect) SSP consults the public "User ENUM" rooted at e164.arpa,
according to the procedures described in [RFC3761]. The SSP must according to the procedures described in [RFC3761]. The SSP must
query for the "E2U+sip" enumservice as described in [RFC3764], but query for the "E2U+sip" enumservice as described in [RFC3764], but
MAY check for other enumservices. The originating (or indirect) SSP may check for other enumservices. The originating (or indirect) SSP
MAY consult a cache or alternate representation of the ENUM data may consult a cache or alternate representation of the ENUM data
rather than actual DNS queries. Also, the SSP may skip actual DNS rather than actual DNS queries. Also, the SSP may skip actual DNS
queries if the originating (or indirect) SSP is sure that the target queries if the originating (or indirect) SSP is sure that the target
address country code is not represented in e164.arpa. address country code is not represented in e164.arpa.
If an im: or pres: URI is chosen for based on an "E2U+im" [RFC3861] If an im: or pres: URI is chosen for based on an "E2U+im" [RFC3861]
or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures or "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures
for resolving these URIs to URIs for specific protocols such a SIP or for resolving these URIs to URIs for specific protocols such a SIP or
XMPP as described in the previous section. XMPP as described in the previous section.
The NAPTR response to the ENUM lookup may be a SIP AoR (such as The NAPTR response to the ENUM lookup may be a SIP AoR (such as
skipping to change at page 7, line 41 skipping to change at page 8, line 41
5.1.2.1. DNS Resolution 5.1.2.1. DNS Resolution
The originating (or indirect) SSP uses the procedures in Section 4 of The originating (or indirect) SSP uses the procedures in Section 4 of
[RFC3263] to determine how to contact the receiving SSP. To [RFC3263] to determine how to contact the receiving SSP. To
summarize the [RFC3263] procedure: unless these are explicitly summarize the [RFC3263] procedure: unless these are explicitly
encoded in the target URI, a transport is chosen using NAPTR records, encoded in the target URI, a transport is chosen using NAPTR records,
a port is chosen using SRV records, and an address is chosen using A a port is chosen using SRV records, and an address is chosen using A
or AAAA records. or AAAA records.
When communicating with another SSP, entities compliant to this When communicating with another SSP, entities compliant to this
document should select a TLS-protected transport for communication document should select a TLS-protected transport [RFC4366] for
from the originating (or indirect) SSP to the receiving SSP if communication from the originating (or indirect) SSP to the receiving
available. SSP if available.
5.1.2.2. Routing Table 5.1.2.2. Routing Table
If there are no End User ENUM records and the originating (or If there are no End User ENUM records and the originating (or
indirect) SSP cannot discover the carrier-of-record or if the indirect) SSP cannot discover the carrier-of-record or if the
originating (or indirect) SSP cannot reach the carrier-of-record via originating (or indirect) SSP cannot reach the carrier-of-record via
SIP peering, the originating (or indirect) SSP may deliver the call SIP peering, the originating (or indirect) SSP may deliver the call
to the PSTN or reject it. Note that the originating (or indirect) to the PSTN or reject it. Note that the originating (or indirect)
SSP may forward the call to another SSP for PSTN gateway termination SSP may forward the call to another SSP for PSTN gateway termination
by prior arrangement using the routing table. by prior arrangement using the routing table.
If so, the originating (or indirect) SSP rewrites the Request-URI to If so, the originating (or indirect) SSP rewrites the Request-URI to
address the gateway resource in the target SSP's domain and MAY address the gateway resource in the target SSP's domain and may
forward the request on to that SSP using the procedures described in forward the request on to that SSP using the procedures described in
the remainder of these steps. the remainder of these steps.
5.1.2.3. LRF to LRF Routing 5.1.2.3. LRF to LRF Routing
Communications between the LRF of two interconnecting SSPs may use Communications between the LRF of two interconnecting SSPs may use
DNS or statically provisioned IP Addresses for reachability. Other DNS or statically provisioned IP Addresses for reachability. Other
inputs to determine the path may be code-based routing, method-based inputs to determine the path may be code-based routing, method-based
routing, Time of day, least cost and/or source-based routing. routing, Time of day, least cost and/or source-based routing.
skipping to change at page 9, line 16 skipping to change at page 10, line 16
Once a trust relationship between the peers is established, the Once a trust relationship between the peers is established, the
originating (or indirect) SSP sends the request. originating (or indirect) SSP sends the request.
5.2. Target SSP Procedures 5.2. Target SSP Procedures
This section describes the Target SSP Procedures. This section describes the Target SSP Procedures.
5.2.1. TLS 5.2.1. TLS
The section defines uses of TLS between two SSPs [RFC5246]. When the The section defines uses of TLS [RFC4366] between two SSPs [RFC5246].
receiving SSP receives a TLS client hello, it responds with its When the receiving SSP receives a TLS client hello, it responds with
certificate. The Target SSP certificate should be valid and rooted its certificate. The Target SSP certificate should be valid and
in a well-known certificate authority. The procedures to rooted in a well-known certificate authority. The procedures to
authenticate the SSP's originating domain are specified in [RFC5922]. authenticate the SSP's originating domain are specified in [RFC5922].
The SF of the Target SSP verifies that the Identity header is valid, The SF of the Target SSP verifies that the Identity header is valid,
corresponds to the message, corresponds to the Identity-Info header, corresponds to the message, corresponds to the Identity-Info header,
and that the domain in the From header corresponds to one of the and that the domain in the From header corresponds to one of the
domains in the TLS client certificate. domains in the TLS client certificate.
5.2.2. Receive SIP Requests 5.2.2. Receive SIP Requests
Once a trust relationship is established, the Target SSP is prepared Once a trust relationship is established, the Target SSP is prepared
skipping to change at page 12, line 24 skipping to change at page 13, line 24
Global Crossing Global Crossing
Rochester, NY - USA Rochester, NY - USA
Email: adam.uzelac@globalcrossing.com Email: adam.uzelac@globalcrossing.com
11. Change Log 11. Change Log
NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION.
o 14: WGLC ended. Ran final nits check prior to sending proto to
the AD and sending the doc to the IESG. Found a few very minor
nits, such as capitalization and replacement of an obsoleted RFC,
which were corrected per nits tool recommendation. The -14 now
moves to the AD and the IESG.
o 13: Closed out all remaining tickets, resolved all editorial o 13: Closed out all remaining tickets, resolved all editorial
notes. notes.
o 12: Closed out several open issues. Properly XML-ized all o 12: Closed out several open issues. Properly XML-ized all
references. Updated contributors list. references. Updated contributors list.
o 11: Quick update to refresh the I-D since it expired, and cleaned o 11: Quick update to refresh the I-D since it expired, and cleaned
up some of the XML for references. A real revision is coming up some of the XML for references. A real revision is coming
soon. soon.
skipping to change at page 13, line 24 skipping to change at page 14, line 30
[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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004. System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3764] Peterson, J., "enumservice registration for Session [RFC3764] Peterson, J., "enumservice registration for Session
Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, Initiation Protocol (SIP) Addresses-of-Record", RFC 3764,
April 2004. April 2004.
[RFC3861] Peterson, J., "Address Resolution for Instant Messaging [RFC3861] Peterson, J., "Address Resolution for Instant Messaging
and Presence", RFC 3861, August 2004. and Presence", RFC 3861, August 2004.
[RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service [RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service
Registration for Presence Services", RFC 3953, Registration for Presence Services", RFC 3953,
January 2005. January 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009. March 2009.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010. RFC 5922, June 2010.
 End of changes. 12 change blocks. 
51 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/