--- 1/draft-ietf-speermint-architecture-16.txt 2010-12-21 00:16:20.000000000 +0100 +++ 2/draft-ietf-speermint-architecture-17.txt 2010-12-21 00:16:20.000000000 +0100 @@ -1,44 +1,44 @@ SPEERMINT D. Malas, Ed. Internet-Draft CableLabs Intended status: Informational J. Livingood, Ed. -Expires: May 12, 2011 Comcast - November 8, 2010 +Expires: June 23, 2011 Comcast + December 20, 2010 - SPEERMINT Peering Architecture - draft-ietf-speermint-architecture-16 + Session PEERing for Multimedia INTerconnect Architecture + draft-ietf-speermint-architecture-17 Abstract This document defines a peering architecture for the Session - Initiation Protocol (SIP) [RFC3261], it's functional components and + Initiation Protocol (SIP) [RFC3261], its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 May 12, 2011. + This Internet-Draft will expire on June 23, 2011. Copyright Notice Copyright (c) 2010 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 @@ -57,80 +57,151 @@ 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reference Architecture . . . . . . . . . . . . . . . . . . . . 4 - 3. Procedures of Inter-Domain SSP Session Establishment . . . . . 5 - 4. Relationships Between Functions/Elements . . . . . . . . . . . 6 - 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 6 - 5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 6 - 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 7 - 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 7 - 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 7 - 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 8 - 5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 8 - 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 8 - 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 9 - 5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 9 - 5.1.3.1. Establishing a Trusted Relationship . . . . . . . 9 - 5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 9 - 5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 9 - 5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 10 - 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 10 - 5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 10 - 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 10 - 6. Address Space Considerations . . . . . . . . . . . . . . . . . 11 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3. Procedures of Inter-Domain SSP Session Establishment . . . . . 6 + 4. Relationships Between Functions/Elements . . . . . . . . . . . 7 + 5. Recommended SSP Procedures . . . . . . . . . . . . . . . . . . 7 + 5.1. Originating or Indirect SSP Procedures . . . . . . . . . . 8 + 5.1.1. The Look-Up Function (LUF) . . . . . . . . . . . . . . 8 + 5.1.1.1. Target Address Analysis . . . . . . . . . . . . . 8 + 5.1.1.2. ENUM Lookup . . . . . . . . . . . . . . . . . . . 9 + 5.1.2. Location Routing Function (LRF) . . . . . . . . . . . 9 + 5.1.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . 9 + 5.1.2.2. Routing Table . . . . . . . . . . . . . . . . . . 10 + 5.1.2.3. LRF to LRF Routing . . . . . . . . . . . . . . . . 10 + 5.1.3. The Signaling Path Border Element (SBE) . . . . . . . 10 + 5.1.3.1. Establishing a Trusted Relationship . . . . . . . 10 + 5.1.3.2. IPSec . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1.3.3. Co-Location . . . . . . . . . . . . . . . . . . . 11 + 5.1.3.4. Sending the SIP Request . . . . . . . . . . . . . 11 + 5.2. Target SSP Procedures . . . . . . . . . . . . . . . . . . 11 + 5.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.2.2. Receive SIP Requests . . . . . . . . . . . . . . . . . 11 + 5.3. Data Path Border Element (DBE) . . . . . . . . . . . . . . 12 + 6. Address Space Considerations . . . . . . . . . . . . . . . . . 12 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This document defines a reference peering architecture for the Session Initiation Protocol (SIP)[RFC3261], it's functional components and interfaces, in the context of session peering for multimedia interconnects. In this process, we define the peering reference architecture, its functional components, and peering - interface functions from the perspective of a SIP Service providers - [RFC5486] network. Thus, it also describes the components and the - steps necessary to establish a session between two SIP Service - Provider (SSP) peering domains. + interface functions from the perspective of a SIP Service Provider's + (SSP) [RFC5486] network. Thus, it also describes the components and + the steps necessary to establish a session between two SSP peering + domains. This architecture enables the interconnection of two SSPs in layer 5 peering, as defined in the SIP-based session peering requirements [I-D.ietf-speermint-requirements]. Layer 3 peering is outside the scope of this document. Hence, the figures in this document do not show routers so that the focus is on layer 5 protocol aspects. This document uses terminology defined in the Session Peering for Multimedia Interconnect (SPEERMINT) Terminology document [RFC5486]. + Apart from normative references included herein, readers may also + find [I-D.ietf-speermint-voip-consolidated-usecases] informative. 2. Reference Architecture The following figure depicts the architecture and logical functions that form peering between two SSPs. + For further details on the elements and functions described in this + figure, please refer to [RFC5486]. The following terms, which appear + in Figure 1, which are documented in [RFC5486] are reproduced here + for simplicity. + + - Data Path Border Element (DBE): A data path border element (DBE) is + located on the administrative border of a domain through which flows + the media associated with an inter-domain session. It typically + provides media-related functions such as deep packet inspection and + modification, media relay, and firewall-traversal support. The DBE + may be controlled by the SBE. + + - E.164 Number Mapping (ENUM): See [RFC3761]. + + - Fully Qualified Domain Name (FQDN): See Section 5.1 of [RFC1035]. + + - Location Routing Function (LRF): The Location Routing Function + (LRF) determines for the target domain of a given request the + location of the SF in that domain, and optionally develops other SED + required to route the request to that domain. An example of the LRF + may be applied to either example in Section 4.3.3 of [RFC5486]. Once + the ENUM response or SIP 302 redirect is received with the + destination's SIP URI, the LRF must derive the destination peer's SF + from the FQDN in the domain portion of the URI. In some cases, some + entity (usually a 3rd party or federation) provides peering + assistance to the originating SSP by providing this function. The + assisting entity may provide information relating to direct (Section + 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) peering + as necessary. + + - Look-Up Function (LUF): The Look-Up Function (LUF) determines for a + given request the target domain to which the request should be + routed. An example of an LUF is an ENUM [4] look-up or a SIP INVITE + request to a SIP proxy providing redirect responses for peers. In + some cases, some entity (usually a 3rd party or federation) provides + peering assistance to the originating SSP by providing this function. + The assisting entity may provide information relating to direct + (Section 4.2.1 of [RFC5486]) or indirect (Section 4.2.2 of [RFC5486]) + peering as necessary. + + - Real-Time Transport Protocol (RTP): See [RFC3550]. + + - Session Initiation Protocol (SIP): See [RFC3261]. + + - Signaling Path Border Element (SBE): A signaling path border + element (SBE) is located on the administrative border of a domain + through which inter-domain session layer messages will flow. It + typically provides signaling functions such as protocol inter-working + (for example, H.323 to SIP), identity and topology hiding, and + Session Admission Control for a domain. + + - Signaling Function (SF): The Signaling Function (SF) performs + routing of SIP requests for establishing and maintaining calls, and + to assist in the discovery or exchange of parameters to be used by + the Media Function (MF). The SF is a capability of SIP processing + elements such as SIP proxies, SBEs, and user agents. + + - SIP Service Provider (SSP): A SIP Service Provider (SSP) is an + entity that provides session services utilizing SIP signaling to its + customers. In the event that the SSP is also a function of the SP, + it may also provide media streams to its customers. Such an SSP may + additionally be peered with other SSPs. An SSP may also interconnect + with the PSTN. An SSP may also be referred to as an Internet + Telephony Service Provider (ITSP). While the terms ITSP and SSP are + frequently used interchangeably, this document and other subsequent + SIP peering-related documents should use the term SSP. SSP more + accurately depicts the use of SIP as the underlying layer 5 signaling + protocol. + +=============++ ++==============+ || || +-----------+ +-----------+ | SBE | +-----+ | SBE | | +-----+ | SIP |Proxy| | +-----+ | | | LUF |<-|------>|ENUM | | | LUF | | | +-----+ | ENUM |TN DB| | +-----+ | SIP | | +-----+ | | ------>| +-----+ | DNS +-----+ | +-----+ | | | LRF |<-|------>|FQDN | | | LRF | | @@ -145,42 +216,41 @@ ------>| |--------------->| | +-----------+ +-----------+ || || SSP1 Network || || SSP2 Network +=============++ ++=============+ Reference Architecture Figure 1 - For further details on the elements and functions described in this - figure, please refer to [RFC5486]. - 3. Procedures of Inter-Domain SSP Session Establishment This document assumes that in order for a session to be established - from a UA in the originating (or indirect) SSP's network to an UA in - the Target SSP's network the following steps are taken: + from a User Agent (UA) in the originating (or indirect) SSP's network + to an UA in the Target SSP's network the following steps are taken: 1. Determine the target or indirect SSP via the LUF. (Note: If the target address represents an intra-SSP resource, the behavior is out-of-scope with respect to this draft.) 2. Determine the address of the SF of the target SSP via the LRF. 3. Establish the session + 4. Exchange the media, which could include voice, video, text, etc. 5. End the session (BYE) - The originating or indirect SSP would likely perform steps 1-4, and - the target SSP would likely perform steps 4-5. + The originating or indirect SSP would likely perform steps 1-4, the + target SSP would likely perform steps 4, and either one is likely to + perform step 5. In the case the target SSP changes, then steps 1-4 would be repeated. This is reflected in Figure 1 that shows the target SSP with its own peering functions. 4. Relationships Between Functions/Elements o An SBE can contain a SF function. o An SF can perform LUF and LRF functions. @@ -258,23 +328,23 @@ If an external E.164 address is the target, the originating (or indirect) SSP consults the public "User ENUM" rooted at e164.arpa, according to the procedures described in [RFC3761]. The SSP must query for the "E2U+sip" enumservice as described in [RFC3764], but may check for other enumservices. The originating (or indirect) SSP may consult a cache or alternate representation of the ENUM data rather than actual DNS queries. Also, the SSP may skip actual DNS queries if the originating (or indirect) SSP is sure that the target address country code is not represented in e164.arpa. - 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 - for resolving these URIs to URIs for specific protocols such a SIP or + If an im: or pres: URI is chosen based on an "E2U+im" [RFC3861] or + "E2U+pres" [RFC3953] enumserver, the SSP follows the procedures for + resolving these URIs to URIs for specific protocols such a SIP or XMPP as described in the previous section. The NAPTR response to the ENUM lookup may be a SIP AoR (such as "sips:bob@example.com") or SIP URI (such as "sips:bob@sbe1.biloxi.example.com"). In the case of when a SIP URI is returned, the originating (or indirect) SSP has sufficient routing information to locate the target SSP. In the case of when a SIP AoR is returned, the SF then uses the LRF to determine the URI for more explicitly locating the target SSP. @@ -509,75 +580,80 @@ Global Crossing Rochester, NY - USA Email: adam.uzelac@globalcrossing.com 11. Change Log NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. + o 17: Misc. updates at the request of Gonzalo, the RAI AD, in order + to clear his review and move to the IESG. This included adding + terminology from RFC 5486 and expanding the document name. + o 16: Yes, one final outdated reference to fix. o 15: Doh! Uploaded the wrong doc to create -14. Trying again. :-) 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 notes. o 12: Closed out several open issues. Properly XML-ized all references. Updated contributors list. 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 soon. -12. Open Issues - - NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION PRIOR TO PUBLICATION. - - o NONE! - -13. References +12. References -13.1. Normative References +12.1. Normative References [I-D.ietf-speermint-requirements] Mule, J., "Requirements for SIP-based Session Peering", draft-ietf-speermint-requirements-10 (work in progress), October 2010. [I-D.ietf-speermint-voipthreats] Seedorf, J., Niccolini, S., Chen, E., and H. Scholz, "Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats and Suggested Countermeasures", draft-ietf-speermint-voipthreats-06 (work in progress), November 2010. + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [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. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC3764] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. [RFC3861] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004. @@ -597,21 +673,21 @@ "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, May 2010. [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010. -13.2. Informative References +12.2. Informative References [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. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.