[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

ENUM                                                       D. Malas, Ed.
Internet-Draft                                                 CableLabs
Intended status: Informational                              T. Creighton
Expires: September 5, 2009                                       Comcast
                                                           March 4, 2009


                        Trunk Group Use in ENUM
                     draft-malas-enum-trunk-sip-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 September 5, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document concludes that incorporating trunk group parameters
   into an Electronic Number (ENUM) response for the Session Initiation



Malas & Creighton       Expires September 5, 2009               [Page 1]


Internet-Draft           Trunk Group Use in ENUM              March 2009


   Protocol (SIP) [RFC3261] service URI is a more effective approach
   compared to defining a new ENUM service type for a 'trunk'.  Upon
   further review of the existing ENUM trunk group draft
   [I-D.ietf-enum-trunkgroup] and practical operator experience, this
   draft recommends the use of the current trunk group contexts as
   defined in [RFC4904] as additional parameters in the E2U+SIP
   enumservice NAPTR record [RFC3403] URI.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
     1.2.  Rationale for Trunk use in the 'E2U+SIP' enumservice
           URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7































Malas & Creighton       Expires September 5, 2009               [Page 2]


Internet-Draft           Trunk Group Use in ENUM              March 2009


1.  Introduction

   ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms
   E.164 numbers into domain names and then uses DNS [RFC1034] features
   such as delegation through NS records, and the use of Naming
   Authority Pointer (NAPTR) records, to look up the communication
   services available for a specific domain name.  This draft refers to
   the look up of the SIP enumservice NAPTR record type.

   The use of trunk groups is well described in [RFC4904] for IP to PSTN
   gateway scenarios.  In addition to this trunk group usage, more and
   more SIP service providers (SSPs) are defining trunk groups as SIP IP
   network end-points.  This can be thought of as a SIP trunk group.
   While there have been other attempts to define a SIP trunk group, in
   this draft, they are simply referred to as the numerical or
   contextual representation of the IP address of a SIP UA or proxy.  It
   is becoming a popular use in SIP peering for determining for a peer's
   ingress SBE or SF an appropriate egress SBE or SF to exit the SSPs
   network.

   One method for identifying a trunk group in ENUM is defined in the
   work in progress [I-D.ietf-enum-trunkgroup].  This draft defines a
   new service type "trunk".  This new service type returns a tel URI
   containing the "tgrp" and "trunk context" parameters that can then be
   carried in IP signaling to control trunk group selection in
   downstream gateways.  While this new ENUM service type may work in
   production environments, it places an unnecessary burden on ENUM
   clients to either assume a trunk group exists by always initiating a
   second ENUM query for the "trunk" service type, or evaluating the
   entire list of NAPTRs in the response for additional service types,
   potentially beyond what it originally queried for.

   Ultimately, this draft concludes there is no need to define a new
   'trunk' service type, because the trunk group is already defined as a
   URI parameter in [RFC4904] and is not a new service such as H.323.
   With this in mind, the additional URI parameters can simply be
   indicated within the returned SIP URI, which simplifies the work an
   ENUM client must do and provides the same end result.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].







Malas & Creighton       Expires September 5, 2009               [Page 3]


Internet-Draft           Trunk Group Use in ENUM              March 2009


1.2.  Rationale for Trunk use in the 'E2U+SIP' enumservice URI

   An evaluation of [RFC3402], [RFC3403], and the work in progress
   [RFC5483] reveals there is no clear definition that says an ENUM
   client MUST only determine the use of one returned NAPTR and ignore
   any other NAPTRs returned by the server.  While this may be true, it
   can also be argued that an ENUM client will only choose one NAPTR
   (and ignore the rest) after evaluating the Services field value,
   along with the ORDER and PREFERENCE/PRIORITY values, and assuming the
   NAPTR identifies an acceptable URI that is not rejected by the client
   due to some other circumstance.  Assuming the ENUM client accepts a
   NAPTR based on this criteria, it is possible a client may never
   evaluate additional service field values.

   The primary argument for this draft takes into consideration that
   trunk group information is defined in [RFC4904] as URI parameters,
   and how it accomplishes the same approach as the 'trunk' service type
   in a more simplified manner.  This should not be considered an
   additional service.

   This is illustrated in the following two examples of a client
   querying the server for a SIP URI available for the telephone number
   +442079460148.  The first example (Example-1) illustrates the
   mechanism defined in [I-D.ietf-enum-trunkgroup], where the trunk
   group parameters are returned in a new ENUM 'trunk' service type.
   The second example (Example-2) shows how the same result can be
   achieved by simply returning the 'trunk group' parameters in the
   existing 'SIP' ENUM service type.

   NOTE: The NAPTR records shown in this section are intended for
   illustration purposes only, and are not intended as good examples of
   how to do ENUM provisioning.

   The following example illustrates a potential scenario indicating how
   an ENUM client MAY not ever evaluate a NAPTR with the 'trunk' service
   type.

   Example-1 (returning 'trunk group' parameters in a new 'trunk'
   service type):

       $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
          NAPTR 10 100 "u" "E2U+sip"  "!^.*$!sip:\1@sbe1.example.com!" .
          NAPTR 10 101 "u" "E2U+sip"  "!^.*$!sip:\1@sbe2.example.com!" .
          NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=TG-1;
                   trunk-context=+44-207@sbe1.example.com;user=phone!" .

   In this example, the ENUM client will likely select the first NAPTR,
   because of a match on the queried Services field value, and the ORDER



Malas & Creighton       Expires September 5, 2009               [Page 4]


Internet-Draft           Trunk Group Use in ENUM              March 2009


   and PREFERENCE/PRIORITY value.  It will never evaluate the 'trunk'
   NAPTR unless the previous two fail for some other circumstance.  Even
   if the client does not specify a service in the original query, the
   ENUM client will likely choose one of the first two NAPTRs due to the
   inherent choice based on the clients understanding of the preferred
   service.  In order for the client to choose the 'trunk' NAPTR, it
   would need to either evaluate two NAPTRs in the response based on a
   client configuration to look for both, or it would have to place a
   query specifically for the 'trunk' service regardless of knowing
   whether trunk parameters exist or not.  This is due to the fact the
   client will always have to assume trunk parameters exist as to avoid
   routing failures due to not having the complete information
   associated with the destination SIP URI.

   It is recognized that one potential option is to change the order of
   the service types to process the 'trunk' service type first.  While
   more and more SIP user agents are supporting ENUM clients, they are
   only supporting a subset of ENUM service types (primarily SIP).
   Adding a new service requires two changes to the SIP ENUM client

   o  it needs to support the new URI type (in this case 'trunk:'), and

   o  a new ENUM service type and processing logic.

   Eliminating the new service type in favor of embedding the parameters
   in the SIP URIs now only requires the SIP ENUM client to support the
   URI extensions with no impact to how it processes NAPTR records or
   how it queries the ENUM server.

   The following example demonstrates how trunk parameters in a 'SIP'
   service URI yields the exact same result without additional rules or
   processing required on the client.

   Example-2 (returning 'trunk group' parameters in the existing 'SIP'
   service type):

       $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
          NAPTR 10 100 "u" "E2U+sip"  "!^.*$!sip:\1;tgrp=TG-1;
                   trunk-context=+44-207@sbe1.example.com;user=phone!" .
          NAPTR 10 101 "u" "E2U+sip"  "!^.*$!sip:\1;tgrp=TG-2;
                   trunk-context=+44-207@sbe2.example.com;user=phone!" .
          NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=TG-1;
                   trunk-context=+44-207@sbe1.example.com;user=phone!" .

   In this example, the additional 'trunk' parameters defined in
   [RFC4904] are included in the SIP URI NAPTR response.  Since, the
   result of the query provides a URI response for the Service field
   'E2U+sip', the client now has all of the information available to it



Malas & Creighton       Expires September 5, 2009               [Page 5]


Internet-Draft           Trunk Group Use in ENUM              March 2009


   to route the call appropriately without having to look at additional
   service NAPTRs or place a specific query for the 'trunk' service
   type.  In addition, it is noticeable that the first and third NAPTRs
   yield the same result for the ENUM client.


2.  Acknowledgments

   The authors of this draft would like to recognize Kevin Johns, David
   Hancock, and Jean-Francois Mule for their comments.


3.  IANA Considerations

   This memo includes no request to IANA.


4.  Security Considerations

   This draft contains no additional security considerations other than
   those already defined within [RFC3764], [RFC4904], and [RFC3761].


5.  Normative References

   [I-D.ietf-enum-trunkgroup]
              Shockey, R. and T. Creighton, "IANA Registration for an
              Enumservice Trunkgroup", draft-ietf-enum-trunkgroup-00
              (work in progress), July 2008.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.




Malas & Creighton       Expires September 5, 2009               [Page 6]


Internet-Draft           Trunk Group Use in ENUM              March 2009


   [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.

   [RFC4904]  Gurbani, V. and C. Jennings, "Representing Trunk Groups in
              tel/sip Uniform Resource Identifiers (URIs)", RFC 4904,
              June 2007.

   [RFC5483]  Conroy, L. and K. Fujiwara, "ENUM Implementation Issues
              and Experiences", RFC 5483, March 2009.


Authors' Addresses

   Daryl Malas (editor)
   CableLabs
   858 Coal Creek Circle
   Louisville, CO  80027
   US

   Phone: +1 303 661 3302
   Email: d.malas@cablelabs.com


   Tom Creighton
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   US

   Phone: +1 215 286 8617
   Email: tom_creighton@cable.comcast.com















Malas & Creighton       Expires September 5, 2009               [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/