One document matched: draft-ietf-speermint-terminology-13.txt
Differences from draft-ietf-speermint-terminology-12.txt
SPEERMINT Working Group D. Malas, Ed.
Internet-Draft Level 3 Communications
Intended status: Informational D. Meyer, Ed.
Expires: May 2008 November 8, 2007
SPEERMINT Terminology
draft-ietf-speermint-terminology-13.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 8, 2008.
Abstract
This document defines the terminology that is to be used in
describing Session PEERing for Multimedia INTerconnect (SPEERMINT).
Table of Contents
1. Introduction...................................................2
2. SPEERMINT Context..............................................3
3. General Definitions............................................4
3.1. Signaling Path Border Element.............................4
3.2. Data Path Border Element..................................4
3.3. Session Establishment Data................................4
3.4. Call Routing..............................................5
3.5. PSTN......................................................5
Malas & Meyer Expires May 8, 2008 [Page 1]
Internet-Draft SPEERMINT Terminology November 2007
3.6. IP Path...................................................6
3.7. Peer Network..............................................6
3.8. Service Provider..........................................6
3.9. SIP Service Provider......................................6
4. Peering........................................................6
4.1. Layer 3 Peering...........................................6
4.2. Layer 5 Peering...........................................7
4.2.1. Direct Peering.......................................7
4.2.2. Indirect Peering.....................................7
4.2.3. Assisted Peering.....................................7
4.2.4. On-demand Peering....................................7
4.2.5. Static Peering.......................................8
4.3. Functions.................................................8
4.3.1. Look-Up Function.....................................8
4.3.2. Location Function....................................8
4.3.3. Signaling Function...................................8
4.3.4. Media Function.......................................8
5. Federations....................................................8
6. Acknowledgments...............................................10
7. Security Considerations.......................................10
8. IANA Considerations...........................................10
9. Normative References..........................................10
Author's Addresses...............................................12
Intellectual Property Statement..................................12
Disclaimer of Validity...........................................12
Copyright Statement..............................................13
Acknowledgment...................................................13
1. Introduction
The term "Voice over IP Peering" (VoIP Peering) has historically
been used to describe a wide variety of aspects pertaining to the
interconnection of service provider networks and to the delivery of
Session Initiation Protocol (SIP [2]) call termination over those
interconnections.
The discussion of these interconnections has at times been confused
by the fact that the term "peering" is used in various contexts to
relate to interconnection at different levels in a protocol stack.
Session Peering for Multimedia Interconnect focuses on how to
identify and route real-time sessions (such as VoIP calls) at the
application layer, and it does not (necessarily) involve the exchange
of packet routing data or media sessions. In particular, "layer 5
network" is used here to refer to the interconnection between SIP
servers, as opposed to interconnection at the IP layer ("layer 3").
The term "peering" will be used throughout the remainder of the
document for the purpose of indicating a layer 5 interconnection.
Malas & Meyer Expires May 8, 2008 [Page 2]
Internet-Draft SPEERMINT Terminology November 2007
This document introduces standard terminology for use in
characterizing real-time session peering. Note however, that while
this document is primarily targeted at the VoIP peering case, the
terminology described here is applicable to those cases in which
service providers peer using SIP signaling for non-voice or quasi-
real-time communications.
The remainder of this document is organized as follows: Section 2
provides the general context for the SPEERMINT Working Group. Section
3 provides the general definitions for real-time SIP based
communication, with initial focus on the VoIP peering case, and
Section 4 defines the terminology describing the various forms of
peering. Finally, Section 5 introduces the concept of federations.
2. SPEERMINT Context
Figure 1 depicts the general session peering context (Not in
chronological order). Note that vertical axis in this figure
describes the layering of identifiers, while the horizontal lines
indicate working group scope. While the SPEERMINT working group is
not limited (or coupled in any way) to the use of E.164 numbers, in
the case shown here an E.164 number [5] is used as a key in an E.164
to Uniform Resource Identifier (URI) mapping (ENUM [4]). The result
of this step (which involves looking up Naming Authority Pointer
(NAPTR) records in the DNS) is a SIP URI, on which the subsequent
call routing is based. Note that the call routing step does not
depend on the presence of an E.164 number. Indeed, the resulting SIP
URI may no longer even contain any numbers of any type. In
particular, the SIP URI can be advertised in various other ways, such
as on a web page.
E.164 number
|
| <--- ENUM lookup of NAPTR in Domain Name System (DNS)
|
|
| ENUM Working Group Scope
=====+====================================================
| SPEERMINT Working Group Scope
Lookup
Discovery <--- Session Establishment Data (SED)
SIP URI
|
| <--- Federation Detection, Policy
| Lookup, and Service Location
|
|
Hostname <--- Addressing and session establishment
|
Malas & Meyer Expires May 8, 2008 [Page 3]
Internet-Draft SPEERMINT Terminology November 2007
| SPEERMINT Working Group Scope
=====+====================================================
| Out of scope for the SPEERMINT Working Group
|
| <--- Lookup of SRV/A and AAAA in DNS
|
IP address
|
| <--- Routing protocols, ARP [14] etc.
|
MAC-address
Figure 1: Session Peering Context
Note that in Figure 1, Session Establishment Data (SED), is the data
used to route a call to the called domain's ingress point (see
Section 3.3 for additional detail).
As illustrated in Figure 1, the ENUM Working Group is primarily
concerned with the acquisition of SED while the SPEERMINT Working
Group is focused on the use of such SED in routing session signaling
requests. Importantly, the SED can be derived from ENUM (i.e., an
E.164 DNS entry) or via any other mechanism available to the user.
Finally, note that the term "call" is being used here in the most
general sense, i.e., call routing and session routing are used
interchangeably.
3. General Definitions
3.1. Signaling Path Border Element
A signaling path border element (SBE) provides signaling functions
such as protocol inter-working (for example, H.323 to SIP), identity
and topology hiding, and Call Admission Control (CAC) for a domain.
Such an SBE is frequently (but need not be) deployed on a domain's
border.
3.2. Data Path Border Element
A data path border element (DBE) provides media-related functions
such as deep packet inspection and modification, media relay, and
firewall support under SBE control. As was the case with the SBE, a
DBE is frequently deployed on a domain's border.
3.3. Session Establishment Data
Session Establishment Data, or SED, is the data used to route a call
to the next hop associated with the called domain's ingress point. A
domain's ingress point can be thought of as the location derived from
Malas & Meyer Expires May 8, 2008 [Page 4]
Internet-Draft SPEERMINT Terminology November 2007
the NAPTR/SRV/A record [1] that resulted from the resolution of the
SED (i.e., a SIP Address of Record (AoR)).
More specifically, the SED is the set of parameters that the outgoing
SBEs need to complete the call, and may include:
. A destination SIP URI
. A SIP proxy to send the INVITE to, including
o Fully Qualified Domain Name (FQDN)
o Port
o Transport Protocol (UDP/TCP/TLS [9/10/11])
. Security Parameters, including
o TLS certificate to use
o TLS certificate to expect
o TLS certificate verification setting
. Optional resource control parameters such as
o Limits on the total number of call initiations to a peer
o Limits on SIP transactions/second
3.4. Call Routing
Call routing is the set of processes and rules used to route a call
and any subsequent mid-dialog SIP requests to their proper (SIP)
destination. More generally, call routing can be thought of as the
set of processes and rules, which are used to route a real-time
session to its termination point.
3.5. PSTN
The term "PSTN" refers to the Public Switched Telephone Network. In
particular, the PSTN refers to the collection of interconnected
circuit-switched voice-oriented public telephone networks, both
commercial and government-owned. In general, PSTN terminals are
addressed using E.164 numbers; various dial-plans (such as emergency
services dial-plans), however, may not directly use E.164 numbers.
Malas & Meyer Expires May 8, 2008 [Page 5]
Internet-Draft SPEERMINT Terminology November 2007
3.6. IP Path
For purposes of this document, an IP path is defined to be a sequence
of zero or more IP router hops.
3.7. Peer Network
This document defines a peer network as the set of SIP user agents
(UAs) (customers) that are controlled by a single administrative
domain and can be reached via some IP path. Note that such a peer
network may also contain end-users who are located on the PSTN (and
hence may also be interconnected with the PSTN), as long as they are
also reachable via some IP path.
3.8. Service Provider
A Service Provider (or SP) is defined to be an entity that provides
layer 3 (IP) transport of SIP signaling and media packets. Example
services may include, but are not limited too, Ethernet Private Line
(EPL), Frame Relay, and IP VPN. An example of this may be an
Internet Service Provider (ISP).
3.9. SIP Service Provider
A SIP Service Provider (or SSP) is an entity that provides
application 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 a SSP may additionally be
peered with other SSPs. A SSP may also interconnect with the PSTN. A
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.
4. Peering
While the precise definition of the term "peering" is the subject of
considerable debate, peering in general refers to the negotiation of
reciprocal interconnection arrangements, settlement-free or
otherwise, between operationally independent service providers.
This document distinguishes two types of peering, Layer 3 Peering and
Layer 5 peering, which are described below.
4.1. Layer 3 Peering
Layer 3 peering refers to interconnection of two service providers'
networks for the purposes of exchanging IP packets which destined for
Malas & Meyer Expires May 8, 2008 [Page 6]
Internet-Draft SPEERMINT Terminology November 2007
one (or both) of the peer's networks. Layer 3 peering is generally
agnostic to the IP payload, and is frequently achieved using a
routing protocol such as Border Gateway Protocol (BGP) [6] to
exchange the required routing information.
An alternate, perhaps more operational definition of layer 3 peering
is that two peers exchange only customer routes, and hence any
traffic between peers terminates on the peer's network or the peer's
customer's network.
4.2. Layer 5 Peering
Layer 5 (Session) peering refers to interconnection of two service
providers for the purposes of routing real-time (or quasi-real time)
call signaling between their respective customers using SIP methods.
Such peering may be direct or indirect (see Section 4.2.1 and Section
4.2.2 below). Note that media streams associated with this signaling
(if any) are not constrained to follow the same set of IP paths.
4.2.1. Direct Peering
Direct peering describes those cases in which two service providers
peer without using an intervening layer 5 network.
4.2.2. Indirect Peering
Indirect, or transit, peering refers to the establishment of either a
signaling and media path or signaling path alone via one (or more)
referral or transit network(s). In this case it is generally required
that a trust relationship is established between the originating
service provider and the transit network on one side; and, the
transit network representing the termination network on the other
side.
4.2.3. Assisted Peering
In this case, some entity (usually a 3rd party or federation)
provides peering assistance to either the originating or terminating
SSP by providing one or more functions (see Section 4.3) assisting in
the routing of SIP requests and the establishment of SIP dialogs and
sessions between peers. The assisting entity may provide information
relating to direct (Section 4.2.1) or indirect (Section 4.2.2)
peering as necessary.
4.2.4. On-demand Peering
Service providers are said to peer on-demand when they are able to
exchange traffic without any pre-association prior to the origination
of a real-time transaction (like a SIP message) between the domains.
Malas & Meyer Expires May 8, 2008 [Page 7]
Internet-Draft SPEERMINT Terminology November 2007
Any information that needs to be exchanged between domains in support
of peering can be learned through a dynamic protocol mechanism. On-
demand peering can occur as direct, indirect, or assisted.
4.2.5. Static Peering
Service providers are said to peer statically when pre-association
between providers is required for the initiation of any real-time
transactions (like a SIP message). Static peering can occur as
direct, indirect, or assisted.
4.3. Functions
The following are terms associated with the functions required for
peering.
4.3.1. Look-Up Function
The Look-Up Function (LUF) provides a mechanism for querying an
internal and/or external database, which maintains a list of peered
host domains.
4.3.2. Location Function
The Location Function (LF) develops SED by discovering the Signaling
Function (SF), and SF's reachable host (IP Address and port).
4.3.3. Signaling Function
The SF performs routing of SIP requests for establishing and
maintaining calls, and to assist in the discovery/exchange of
parameters to be used by the Media Function (MF).
4.3.4. Media Function
The MF performs media related functions such as media transcoding and
media security implementation between two SSPs.
5. Federations
A federation is a group of SSPs which agree to receive calls from
each other via SIP, and who agree on a set of administrative rules
for such calls (settlement, abuse-handling, ...) and the specific
rules for the technical details of the peering.
A federation may provide some or all of the following functionality:
. Common static policies
Malas & Meyer Expires May 8, 2008 [Page 8]
Internet-Draft SPEERMINT Terminology November 2007
o Routing
o Domain
o Location
o Next hop
o Network-to-Network Interface (NNI)
. Common dynamic policies
o Congestion control
o Codec preference
o Authentication preference
o Quality monitoring capabilities (e.g. RTP Control Protocol
(RTCP) [12], RTCP Extended Reports (RTCP XR) [13])
. Policy management (enforcement)
o Ad-hoc
o Published in the DNS, or
o Policy might also be managed by a federation entity
. A federated ENUM root
. Address resolution mechanisms
. Session signaling (via federation policy)
. Media streams (via federation policy)
. Federation security policies
. Peering policies
. Other layer 2 and layer 3 policies
. Security parameters
. Optional resource control parameters
Finally, note that a SSP can be a member of
Malas & Meyer Expires May 8, 2008 [Page 9]
Internet-Draft SPEERMINT Terminology November 2007
o No federation (e.g., the SSP has only bilateral peering
agreements)
o A single federation
o Multiple federations
and an SSP can have any combination of bi-lateral and multi-
lateral (i.e., federated) peers.
6. Acknowledgments
Many of the definitions were gleaned from detailed discussions on the
SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, Mike Hammer,
Eli Katz, Gaurav Kulshreshtha, Otmar Lendl, Jason Livingood,
Alexander Mayrhofer, Jean-Francois Mule, Jonathan Rosenberg, David
Schwartz, Richard Shockey, Henry Sinnreich, Richard Stastny, Hannes
Tschofenig, Dan Wing, and Adam Uzelac all made valuable contributions
to early versions of this document. Patrik Faltstrom also made many
insightful comments to early versions of this draft, and contributed
the basis of Figure 1.
7. Security Considerations
This document introduces no new security considerations. However, it
is important to note that session peering, as described in this
document, has a wide variety of security issues that should be
considered in documents addressing both protocol and use case
analyzes.
8. IANA Considerations
This document creates no new requirements on IANA namespaces [7].
9. Normative References
[1] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[2] 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.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
Malas & Meyer Expires May 8, 2008 [Page 10]
Internet-Draft SPEERMINT Terminology November 2007
[4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[5] International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-T Recommendation
E.164, 02 2005.
[6] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[8] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes", RFC 4594, August 2006.
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[10] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[11] Postel, J., "DoD Standard Transmission Control Protocol", RFC
761, January 1980.
[12] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP:
A Transport Protocol for Real-Time Applications", RFC 3550,
July 2003.
[13] Friedman, T., Caceres, R., Clark, A., "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[14] Plummer, David C., "An Ethernet Address Resolution Protocol",
RFC 826, November 1982.
Malas & Meyer Expires May 8, 2008 [Page 11]
Internet-Draft SPEERMINT Terminology November 2007
Author's Addresses
Daryl Malas
Level 3 Communications LLC
1025 Eldorado Blvd.
Broomfield, CO 80021
USA
Email: daryl.malas@level3.com
David Meyer
Email: dmm@1-4-5.net
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Malas & Meyer Expires May 8, 2008 [Page 12]
Internet-Draft SPEERMINT Terminology November 2007
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Malas & Meyer Expires May 8, 2008 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 11:28:33 |