One document matched: draft-ietf-speermint-terminology-02.txt
Differences from draft-ietf-speermint-terminology-01.txt
Network Working Group D. Meyer
Internet-Draft August 7, 2006
Expires: February 8, 2007
SPEERMINT Terminology
draft-ietf-speermint-terminology-02.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 February 8, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines the terminology that is to be used by the
Session PEERing for Multimedia INTerconnect Working Group
(SPEERMINT). It has as its primary objective to focus the working
group during its discussions, and when writing requirements, gap
analysis and other solutions oriented documents.
Meyer Expires February 8, 2007 [Page 1]
Internet-Draft SPEERMINT Terminology August 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SPEERMINT Context . . . . . . . . . . . . . . . . . . . . . . 3
3. General Definitions . . . . . . . . . . . . . . . . . . . . . 4
3.1. Call Routing Data . . . . . . . . . . . . . . . . . . . . 4
3.2. Call Routing . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Network . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Service Provider (SP) . . . . . . . . . . . . . . . . . . 5
3.6. Voice Service Provider (VSP) . . . . . . . . . . . . . . . 5
4. Peering . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Layer 3 Peering . . . . . . . . . . . . . . . . . . . . . 6
4.2. Layer 5 (Session) Peering . . . . . . . . . . . . . . . . 6
4.3. Direct Peering . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Indirect (Transit) Peering . . . . . . . . . . . . . . . . 6
5. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Carrier of Record . . . . . . . . . . . . . . . . . . . . 7
5.2. User ENUM . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . 8
6. Federations . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Federation Functionality . . . . . . . . . . . . . . . . . 9
6.2. Announcement of Federation Membership . . . . . . . . . . 9
6.3. Example Federation Rules . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Meyer Expires February 8, 2007 [Page 2]
Internet-Draft SPEERMINT Terminology August 2006
1. Introduction
The term "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 SIP 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"). Finally, the terms "peering" and
"interconnect" are used interchangeably throughout this document.
This document introduces standard terminology for use in
characterizing real-time session interconnection. Note however, that
while this document is primarily targeted at the VoIP interconnect
case, the terminology described here is applicable to those cases in
which service providers interconnect using SIP signaling for real-
time 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 interconnect case, and
Section 5 briefly touches on terms from the ENUM Working Group.
Finally, Section 6 introduces the concept of federations.
2. SPEERMINT Context
Figure 1 depicts the general VoIP interconnect context. In the case
shown here, an E.164 number [ITU.E164.1991] is used as a key by ENUM
to retrieve a NAPTR record [RFC3404] from the DNS, which in turn
resolved into a SIP URI. Call routing is based on the resulting SIP
URI. 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, and the SIP URI can be advertised in various
other ways, such as on a web page.
Meyer Expires February 8, 2007 [Page 3]
Internet-Draft SPEERMINT Terminology August 2006
E.164 number <--- Peer Discovery
|
| <--- ENUM lookup of NAPTR in DNS
|
|
| ENUM Working Group Scope
=====+====================================================
| SPEERMINT Working Group Scope
|
SIP URI <--- Call Routing Data (CRD)
|
|
| <--- Federation Detection, Policy
| Lookup, and Service Location
|
|
Hostname <--- Addressing and session establishment
|
| SPEERMINT Working Group Scope
=====+====================================================
| Out of scope for the SPEERMINT Working Group
|
| <--- Lookup of A and AAAA in DNS
|
Ip address
|
| <--- Routing protocols, ARP etc
|
Mac-address
Figure 1: Session Interconnect Context
The ENUM Working Group is primarily concerned with the acquisition of
Call Routing Data, or CRD (i.e., above the double line in Figure 1),
while the SPEERMINT Working Group is focused on the use of such CRD.
Importantly, the CRD can be derived from ENUM (i.e., an E.164 DNS
entry), or via any other mechanism available to the user.
3. General Definitions
3.1. Call Routing Data
Call Routing Data, or CRD, is a SIP URI used to route a call (real-
time, voice or other type) to the called domain's ingress point. A
domain's ingress point can be thought of as the location pointed to
by the SRV record that resulted from the resolution of the CRD (i.e.,
a SIP URI).
Meyer Expires February 8, 2007 [Page 4]
Internet-Draft SPEERMINT Terminology August 2006
3.2. Call Routing
Call routing is the set of processes, rules, and CRD used to route a
call to its proper (SIP) destination. More generally, call routing
can be thought of as the set of processes, rules and CRD which are
used to route a real-time session to its termination (ingress) point.
3.3. 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, noting that various dial-plans (such
as emergency services dial-plans) may not directly use E.164 numbers.
3.4. Network
For purposes of this document and the SPEERMINT and ENUM Working
Groups, a network is defined to be the set of SIP servers and end-
users (customers) that are controlled by a single administrative
domain and can be reached via layer 3 (IP) peering. The network may
also contain end-users who are located on the PSTN, as long as they
are also reachable via layer 3 (IP) peering.
3.5. Service Provider (SP)
A Service Provider (or SP) is defined to be an entity that controls a
"network" as defined in Section 3.4, and provides transport of SIP
signaling and media packets.
3.6. Voice Service Provider (VSP)
A Voice Service Provider (or VSP) is an entity that provides
transport of SIP signaling (and possibly media streams) to its
customers. Such a service provider may additionally be
interconnected with other service providers; that is, it may "peer"
with other service providers. A VSP may also interconnect with the
PSTN.
Note that as soon as a ingress point is advertised via a SRV record,
anyone can find that ingress point and hence can send calls there.
This is very similar to sending mail to a SMTP server based on the
existence of a MX record.
Finally, note the concept of a VSP is a subset of the possible SP
types. That is, a VSP is an SP, but it is not necessary that an SP
be a VSP.
Meyer Expires February 8, 2007 [Page 5]
Internet-Draft SPEERMINT Terminology August 2006
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
for the purposes of exchanging IP packets which destined for 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 BGP [RFC1771] 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 one of the peer's network.
4.2. Layer 5 (Session) Peering
Layer 5 (Session) peering refers to interconnection of two service
providers for the purposes of routing real-time (or quasi-real time)
secure call signaling between their respective customers using SIP
methods. Such interconnection may be direct or indirect (see
Section 4.3 and Section 4.4 below). Note that media streams
associated with this signaling (if any) are not constrained to follow
the same set of paths.
4.3. Direct Peering
Direct peering describes those cases in which two domains
interconnect without using an intervening layer 5 network. Both
domains must have a trust relationship established (for example, they
may know they belong to the same federation; see Section 6 below)
before opening up a secure layer 5 communication path.
4.4. Indirect (Transit) Peering
Indirect (transit) peering refers to the establishment of a secure
signaling path via one (or more) referral or transit network(s). In
this case it is required that a trust relationship is established
between the originating domain and the transit network on one side,
and the transit network and the termination network on the other
Meyer Expires February 8, 2007 [Page 6]
Internet-Draft SPEERMINT Terminology August 2006
side. Both trust relationships must exist before opening up a secure
communication path on L5.
5. ENUM
ENUM [RFC3761] defines how the Domain Name System (DNS) can be used
for identifying available services connected to one E.164 number.
5.1. Carrier of Record
For purposes of this document, "Carrier of Record", or COR, refers to
the entity to which an E.164 number has been assigned to (or ported
to). More specifically, the COR can be defined can defined as
follows [I-D.ietf-enum-infrastructure-enum-reqs]:
o If the number in question has not been ported, then the COR is the
Service Provider to which the E.164 number was allocated for end
user assignment (either the National Regulatory Authority (NRA) or
the International Telecommunication Union (ITU) makes these
assignments), or
o If the number has been ported, the COR is the service provider to
which the number was ported, or
o If the number is assigned directly to end users, the COR is the
service provider that the end user number assignee has chosen to
provide a Public Switched Telephone Network/Public Land Mobile
Network (PSTN/PLMN) point-of-interconnect for the number.
Finally, note that the exact definition of who and what is a COR is
ultimately the responsibility of the relevant NRA.
5.2. User ENUM
User ENUM is generally defined as the set of administrative policies
and procedures surrounding the use of the e164.arpa domain for
Telephone Number to URI resolution [RFC3761]. In the User ENUM case,
the entity (or person) having the right to use a number has control
the content of the associated domain and thus the zone content (at
the very least, there is local control over the content of the zone).
From a domain registration perspective, the end user number assignee
is thus the registrant [I-D.ietf-enum-infrastructure-enum-reqs].
Policies and procedures for the registration of telephone numbers
within all branches of the e164.arpa tree are Nation State issues by
agreement with the Internet Architecture Board (IAB) and ITU.
National Regulatory Authorities have generally defined User ENUM
Meyer Expires February 8, 2007 [Page 7]
Internet-Draft SPEERMINT Terminology August 2006
Registrants as the E.164 number holder as opposed to the COR that
issued the phone number.
5.3. Infrastructure ENUM
Infrastructure ENUM (I-ENUM) is generally regarded as the use of a
separate branch the e164.arpa tree, such as ie164.arpa to permit
service providers to exchange phone number to URI data in order to
find points of interconnection. The current theory of Infrastructure
ENUM is that only the COR for a particular E.164 number is permitted
to provision data for that E.164 within that portion of the e164.arpa
tree.
In infrastructure ENUM, only the COR may enter data in the
corresponding domain. The COR may also enter CRD (i.e., a SIP URI)
to allow other SPs to to route sessions to its network.
Finally, note that ENUM is not constrained to carry only data (CDR)
as defined by SPEERMINT. In particular, an important class of CRD,
the tel URIs [RFC3966] may be carried in ENUM. Such tel URIs are
most frequently used to interconnect with the PSTN directly, and are
out of scope for SPEERMINT. On the other hand, PSTN endpoints served
by a COR and reachable via CDR and networks as defined in Section 3.1
and Section 3.4 are in scope for SPEERMINT.
6. Federations
The domain policy DDDS application [I-D.lendl-domain-policy-ddds]
defines a method with which a domain owner can announce the policy it
will use to accept incoming calls. This section introduces a policy
type for use with that framework, known as federations
[I-D.lendl-speermint-federations].
Note that [I-D.lendl-domain-policy-ddds] does not define what these
rules can be or how they might be communicated to the members of a
federation. Further, there is no requirement that such rules are in
any way public.
Briefly, a federation is a group of SPs which agree:
* To receive calls from each other via SIP,
* On a set of administrative rules for such calls (settlement,
abuse-handling, ...), and
* On specific rules for the technical details of the
interconnection.
Meyer Expires February 8, 2007 [Page 8]
Internet-Draft SPEERMINT Terminology August 2006
6.1. Federation Functionality
A federation may provide some or all of the following functionality:
* Common policies
+ Policy might be ah-hoc, and published in the DNS (e.g.,
[I-D.lendl-domain-policy-ddds], or
+ 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
* Interconnection policies
* Other layer 2 and layer 3 policies
Finally, note that a SP can be a member of
* No federation (e.g., the SP has only bilateral peering
agreements)
* A single federation
* Multiple federations
and an SP can have any combination of bi-lateral and multi-lateral
(i.e., federated) interconnections.
6.2. Announcement of Federation Membership
Announcement of federation membership is typically made by the
terminating SP, using one or more of the following mechanisms:
* I-ENUM
* A Private ENUM Federation discovery mechanism
* DNS
Meyer Expires February 8, 2007 [Page 9]
Internet-Draft SPEERMINT Terminology August 2006
6.3. Example Federation Rules
Example federation rules might include the following:
o A set of SPs form an association and agree to accept calls from
each other via the public Internet as long as the SIP call uses
TCP/TLS as transport protocol and presents a X.509 cert which was
signed by the association's own CA.
o A set of SPs build a L3 network dedicated to VoIP peering (e.g.,
the 3GPP GRX). The further agree to accept calls from all
participants in that network and bill each other via a
clearinghouse.
o A set of SPs agree to accept calls originating from within the
same country. They use a set of firewall rules to block calls
from abroad.
o A company sets up a SIP proxy which acts as a forwarding proxy
between the SIP proxies of all participating SPs. The group of
these SP form a federation whose technical rules state that calls
have to be routed via that central proxy.
7. Acknowledgments
Many of the definitions were gleaned from detailed discussions on the
SPEERMINT, ENUM, and SIPPING mailing lists. Scott Brim, Eli Katz,
Mike Hammer, Gaurav Kulshreshtha, Jason Livingood, Jean-Francois
Mule, David Schwartz, Richard Shockey, Henry Sinnreich, Richard
Stastny, 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.
8. Security Considerations
This document introduces no new security considerations. However, it
is important to note that Session interconnect, 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.
9. IANA Considerations
This document creates no new requirements on IANA namespaces
Meyer Expires February 8, 2007 [Page 10]
Internet-Draft SPEERMINT Terminology August 2006
[RFC2434].
10. References
10.1. Normative References
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[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.
[ITU.E164.1991]
International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, 1991.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
10.2. Informative References
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[I-D.ietf-enum-infrastructure-enum-reqs]
Lind, S. and P. Pfautz, "Infrastrucure ENUM Requirements",
draft-ietf-enum-infrastructure-enum-reqs-02 (work in
progress), April 2006.
[I-D.lendl-speermint-federations]
Lendl, O., "A Federation based VoIP Peering Architecture",
draft-lendl-speermint-federations-01 (work in progress),
June 2006.
[I-D.lendl-domain-policy-ddds]
Lendl, O., "The Domain Policy DDDS Application",
draft-lendl-domain-policy-ddds-01 (work in progress),
June 2006.
Meyer Expires February 8, 2007 [Page 11]
Internet-Draft SPEERMINT Terminology August 2006
Author's Address
David Meyer
Email: dmm@1-4-5.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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 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.
Intellectual Property
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.
Meyer Expires February 8, 2007 [Page 12]
Internet-Draft SPEERMINT Terminology August 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Meyer Expires February 8, 2007 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 22:31:41 |