Subject: [Enum] RE: [voipeer] draft-meyer-voipeer-terminology-03.txt

From: "Stastny Richard" <[email-masked]>
Date: Mon, 24 Oct 2005 10:42:43 +0200

Hi Dave,

I minor comment to Figure 1

In the ENUM scope,

E.164 number <--- Peer Discovery
                |
                | <--- ENUM lookup of NAPTR in DNS
                |
                |
                | ENUM Working Group Scope

I would add for clarification

E.164 number <--- Peer Discovery
                |
                | <--- ENUM lookup of NAPTR in DNS to retrieve
                       Call Routing Data (CRD) e.g. a SIP URI
                |
                |
                | ENUM Working Group Scope

Cheers
Richard

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of David Meyer
> Sent: Thursday, October 20, 2005 10:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [voipeer] draft-meyer-voipeer-terminology-03.txt
> 
> 	Folks,
> 
> 	Here's the latest on this one (posted here as I'm not
> 	sure what the secretariat's posting rate is these
> 	days). I've included all the comments, AFAICT.
> 
> 	There had been another suggestion to "harmonize" with
> 	G.8080 terminology, which I am so far resisting
> 	(comments on that)?
> 
> 
> 	Thanks,
> 
> 	Dave
> 
> ---
> 
> Network Working Group                                           D.
Meyer
> Internet-Draft                                          October 20,
2005
> Expires: April 23, 2006
> 
> 
>         Terminology for Describing VoIP Peering and Interconnect
>                  draft-meyer-voipeer-terminology-03.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 23, 2006.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2005).
> 
> Abstract
> 
>    This document defines the terminology that is to be used by the
Voice
>    Over IP Peering and Interconnect Working Group (voipeer), and has
as
>    its primary objective to focus the VOIPEER Working Group during its
>    discussions, and when writing requirements, gap analysis and other
>    solutions oriented documents.
> 
> 
> 
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
1]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
> Table of Contents
> 
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
3
>    2.  Context  . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
>    3.  General Definitions  . . . . . . . . . . . . . . . . . . . . .
4
>      3.1.  Call Routing Data  . . . . . . . . . . . . . . . . . . . .
4
>      3.2.  Call Routing . . . . . . . . . . . . . . . . . . . . . . .
4
>      3.3.  PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
>      3.4.  Network  . . . . . . . . . . . . . . . . . . . . . . . . .
5
>      3.5.  VoIP Service Provider  . . . . . . . . . . . . . . . . . .
5
>      3.6.  Carrier  . . . . . . . . . . . . . . . . . . . . . . . . .
5
>      3.7.  Peering  . . . . . . . . . . . . . . . . . . . . . . . . .
5
>        3.7.1.  Layer 3 Peering  . . . . . . . . . . . . . . . . . . .
6
>        3.7.2.  Layer 5 Peering  . . . . . . . . . . . . . . . . . . .
6
>      3.8.  VoIP Peering . . . . . . . . . . . . . . . . . . . . . . .
6
>    4.  ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
>      4.1.  Carrier of Record  . . . . . . . . . . . . . . . . . . . .
6
>      4.2.  Public ENUM  . . . . . . . . . . . . . . . . . . . . . . .
6
>      4.3.  Private ENUM . . . . . . . . . . . . . . . . . . . . . . .
7
>      4.4.  Carrier ENUM . . . . . . . . . . . . . . . . . . . . . . .
7
>    5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . .
7
>    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .
7
>    7.  Security Considerations  . . . . . . . . . . . . . . . . . . .
8
>    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .
8
>    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .
8
>      9.1.  Normative References . . . . . . . . . . . . . . . . . . .
8
>      9.2.  Informative References . . . . . . . . . . . . . . . . . .
8
>    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .
10
>    Intellectual Property and Copyright Statements . . . . . . . . . .
11
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
2]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
> 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.  VoIP peering focuses on how to identify and
route
>    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 VoIP 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 VOIPEER Working Group, and
>    Section 3 provides the general definitions for real-time SIP based
>    communication, with focus on the VoIP interconnect case.  Section 4
>    briefly touches on terms from the ENUM Working Group.  Finally,
>    Section 5 provides comments on usage.
> 
> 
> 2.  Context
> 
>    Figure 1 depicts the general VoIP interconnect context.  In this
>    case, the caller uses an E.164 number [ITU.E164.1991] as the "name"
>    of the called user.  Note that this E.164 number is not an address,
>    since at this point we do not have information about where the
named
>    endpoint is located.  In the case shown here, an E.164 number is
used
>    as a key to retrieve a NAPTR recored [RFC3404] from the DNS, which
in
>    turn resolved into a SIP URI.  Call routing is based on this SIP
URI.
>    The call routing step does not depend on the presence of an E.164
>    number; the SIP URI can be advertised in various other ways, such
as
>    on a web page.  Finally, note that the subsequent lookup steps,
>    namely, look up of SRV, A, and AAAA records (as well as any routing
>    steps below that) are outside the scope of VOIPEER.
> 
> 
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
3]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
>            E.164 number <--- Peer Discovery
>                 |
>                 | <--- ENUM lookup of NAPTR in DNS
>                 |
>                 |
>                 | ENUM Working Group Scope
>            =====+=======================================
>                 | VOIPEER Working Group Scope
>                 |
>                 |
>            SIP URI <--- Call Routing Data (CRD)
>                 |
>                 | <--- Service Location (Lookup of SRV in DNS)
>                 |
>                 |
>            Hostname <--- VoIP addressing and session establishment
>                 |
>                 | <---- Lookup of A and AAAA in DNS
>                 |
>            Ip address
>                 |
>                 | <---- Routing protocols, ARP etc
>                 |
>            Mac-address
> 
>    Figure 1: VoIP 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 VOIPEER 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).
> 
> 3.2.  Call Routing
> 
>    Call routing is the set of processes, rules, and CRD used to route
a
>    VoIP call to its proper (SIP) destination.  More generally, call
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
4]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
>    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 VOIPEER 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.  The network may also contain end-users who are located on
>    the PSTN.
> 
> 3.5.  VoIP Service Provider
> 
>    A VoIP service provider 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 VoIP service provider 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.
> 
> 3.6.  Carrier
> 
>    The term carrier is defined to be a service provider authorized to
>    issue E.164 numbers [ITU.E164.1991] for the provisioning of PSTN
>    service under the authority of a National Regulatory Authority
(NRA).
> 
> 3.7.  Peering
> 
>    While the precise definition of the term "peering" is the subject
of
>    some debate, peering in general refers to the negotiation of
>    reciprocal interconnection arrangements, settlement-free or
>    otherwise, between operationally independent service providers.
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
5]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
>    This document distinguishes two types of peering, Layer 3 Peering
and
>    Layer 5 peering, which are described below.
> 
> 3.7.1.  Layer 3 Peering
> 
>    Layer 3 peering refers to interconnection of two service providers
>    for the purposes of exchanging IP packets.  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.
> 
> 3.7.2.  Layer 5 Peering
> 
>    Layer 5 peering refers to interconnection of two service providers
>    for the purposes of SIP signaling.  Note that in the layer 5
peering
>    case, there is no intervening network.  That is, for purposes of
this
>    discussion, there is no such thing as a "Layer 5 Transit Network".
> 
> 3.8.  VoIP Peering
> 
>    VoIP peering is defined to be a layer 5 peering between two VoIP
>    providers for purposes of routing real-time (or quasi-real time)
call
>    signaling between their respective customers.  Media streams
>    associated with this signaling (if any) are not constrained to
follow
>    the same set of paths.
> 
> 
> 4.  ENUM
> 
>    ENUM [RFC3761] defines how the Domain Name System (DNS) can be used
>    for identifying available services connected to one E.164 number.
> 
> 4.1.  Carrier of Record
> 
>    For purposes of this document, "Carrier of Record", or COR, refers
to
>    the entity that provides PSTN service for an E.164 number
[I-D.lind-
>    infrastructure-enum-reqs].  The exact definition of who and what is
a
>    COR is ultimately the responsibility of the relevant national
>    authority.
> 
> 4.2.  Public ENUM
> 
>    Public ENUM is generally defined as the set administrative policies
>    and procedures surrounding the use of the e164.arpa domain for
>    Telephone Number to URI resolution [RFC3966].  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 IAB and ITU.  National Regulatory Authorities have
generally
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
6]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
>    defined Public ENUM Registrants as the E.164 number holder as
opposed
>    to the COR that issued the phone number.
> 
> 4.3.  Private ENUM
> 
>    Private ENUM is generally regarded as one or more technologies
>    (including DNS and SIP Redirect) that service providers or
>    enterprises may use to exchange phone number to URI mappings in a
>    private secure manner.  Private ENUM may be used in any mutually
>    agreed upon domain.  Records in Private ENUM may be globally
visible
>    but in most cases are not visible to the global Internet and are
>    protected using a variety of security technologies such as
split-DNS,
>    VPN's or various forms or authentication and authorization.
>    Technical comments on issues surrounding split-DNS can be found in
>    [RFC2826].
> 
> 4.4.  Carrier ENUM
> 
>    Carrier ENUM is generally regarded as the use of a separate branch
>    the e164.arpa tree, such as 4.4.c.e164.arpa to permit service
>    providers to exchange phone number to URI data in order to find
>    points of interconnection.  The current theory of Carrier 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 carrier ENUM case, only the COR may enter data in the
>    corresponding domain.  The COR may also enter CRD (i.e., a SIP URI)
>    to allow other VoIP Service Providers to route calls to its
network.
> 
>    Finally, note that ENUM is not constrained to carry only data (CDR)
>    as defined by VOIPEER.  In particular, an 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 VOIPEER.  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 VOIPEER.
> 
> 
> 5.  Conclusions
> 
> 
> 6.  Acknowledgments
> 
>    Many of the definitions were gleaned from detailed discussions on
the
>    VOIPEER, ENUM, and SIPPING mailing lists.  Scott Brim, Mike Hammer,
>    Jean-Francois Mule, Richard Shocky, and Richard Stastny made
valuable
>    contributions to early revisions of this document.  Patrik
Faltstrom
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
7]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
>    also made many insightful comments to early versions of this draft,
>    and contributed the basis of Figure 1.
> 
> 
> 7.  Security Considerations
> 
>    This document itself introduces no new security considerations.
>    However, it is important to note that VoIP interconnect 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
>    [RFC2434].
> 
> 
> 9.  References
> 
> 9.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.
> 
> 9.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.
> 
>    [RFC2826]  Internet Architecture Board, "IAB Technical Comment on
the
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
8]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
>               Unique DNS Root", RFC 2826, May 2000.
> 
>    [I-D.lind-infrastructure-enum-reqs]
>               Lind, S., "Infrastructure ENUM Requirements",
>               draft-lind-infrastructure-enum-reqs-00 (work in
progress),
>               July 2005.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                 [Page
9]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
> Author's Address
> 
>    David Meyer
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                [Page
10]
> 
> 
> Internet-Draft   Terminology for Describing VoIP Peering    October
2005
> 
> 
> 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
>    [email-masked].
> 
> 
> 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 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.
> 
> 
> Copyright Statement
> 
>    Copyright (C) The Internet Society (2005).  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.
> 
> 
> 
> 
> Meyer                    Expires April 23, 2006                [Page
11]

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum