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

Versions: 00 01

Network Working Group                                           D. Malas
Internet-Draft                                                 CableLabs
Intended status: Informational                              T. Creighton
Expires: April 29, 2010                                          Comcast
                                                        October 26, 2009


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

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 April 29, 2010.

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 describes a method for incorporating trunk group
   parameters into an E.164 Number Mapping (ENUM) response for the



Malas & Creighton        Expires April 29, 2010                 [Page 1]


Internet-Draft           Trunk Group Use in ENUM            October 2009


   Session Initiation Protocol (SIP) [RFC3261] service URI.  It defines
   the use of 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
     1.2.  Trunk use in the 'E2U+SIP' enumservice URI  . . . . . . . . 4
     1.3.  Why Not Create a new ENUM Service Type? . . . . . . . . . . 6
     1.4.  ENUM Client, Proxy, and User Agent Considerations . . . . . 7
     1.5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
     1.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
     1.7.  Security Considerations . . . . . . . . . . . . . . . . . . 8
   2.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9


































Malas & Creighton        Expires April 29, 2010                 [Page 2]


Internet-Draft           Trunk Group Use in ENUM            October 2009


1.  Introduction

   ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms
   E.164 numbers into SIP URIs and then uses DNS [RFC1034] features such
   as delegation through NS records, or the use of Naming Authority
   Pointer (NAPTR) records, to provide the communication services
   available for a specific domain name.  This draft refers to the
   resulting SIP enumservice NAPTR record type received by an ENUM
   client request.  Simplified methods for provisioning call routing
   data in ENUM servers have developed a desire among SIP Service
   Providers (SSPs) to manage all call routing data in an ENUM database
   versus managing some call routing in both ENUM and DNS.

   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 an IPv4/v6 address or a
   fully qualified domain name (FQDN) representing the target SIP UA or
   proxy.  In addition, SIP trunk groups are becoming popular for
   defining an associated egress Signaling Path Border Element (SBE) for
   preferred routing to a peer's ingress SBE.


   +=====================++                 ++====================+
                         ||                 ||
       SSP1 Network  +--------+             ||       SSP2 Network
   ssp1.example.com  |        |             ||   ssp2.example.com
                +--->|  SBE1  |---+         ||
                |    |        |   |         ||
                |    +--------+   |         ||
                |        ||       |         ||
                |        ||       |         ||
    +-------+   |        ||       |     +--------+     +-------+
    |       |---+        ||       +---->|        |---->|       |
    | Proxy |            ||             |  SBE3  |     | Proxy |
    |       |---+        ||       +---->|        |---->|       |
    +-------+   |        ||       |     +--------+     +-------+
                |        ||       |         ||
                |        ||       |         ||
                |    +--------+   |         ||
                |    |        |   |         ||
                +--->|  SBE2  |---+         ||
                     |        |             ||
                     +--------+             ||
                         ||                 ||
   +=====================++                 ++====================+



Malas & Creighton        Expires April 29, 2010                 [Page 3]


Internet-Draft           Trunk Group Use in ENUM            October 2009


   The above figure illustrates the problem.  SSP1 has two options to
   send a request to SSP2.  For reasons outside the scope of this draft,
   SSP1 would prefer to use SBE2 to send a request to SSP2.  Based on
   the information from SSP2, an example ENUM response for SSP1 would
   look something like the following:

   $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:\1@sbe3.ssp2.example.com!" .


   While SSP1 can use a subsequent private DNS look-up on
   sbe3.ssp2.example.com to discover and manipulate a preferred call
   routing path to SBE3, it prefers to use defined trunk group
   parameters to specify SBE2 as the egress point to reach SBE3.  Trunk
   group use is especially applicable if SSP2 uses an IPv4/v6 address to
   specify SBE3 with no additional DNS look-ups to discover the
   preferred path via SBE2.  This draft defines a method for SSP1 to
   determine the preferred call routing path to reach SBE3 through the
   results of an ENUM query.

1.1.  Terminology

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

   Additional terms used in this document for describing aspects of the
   problem and solution are defined in RFC 5486 [RFC5486].

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

   The following example shows how the'trunk group' parameters are
   returned 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.

   Example:

   $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!" .

   In this example, the additional 'trunk' parameters defined in
   [RFC4904] are included in the SIP URI NAPTR response.  Since, the



Malas & Creighton        Expires April 29, 2010                 [Page 4]


Internet-Draft           Trunk Group Use in ENUM            October 2009


   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
   to route the call.  The following figure and subsequent explanation
   illustrates this in more detail:


   +=====================++                 ++====================+
                         ||                 ||
       SSP1 Network  +--------+             ||       SSP2 Network
   ssp1.example.com  |        |             ||   ssp2.example.com
                +--->|  SBE1  |---+         ||
                |    |        |   |         ||
                |    +--------+   |         ||
                |        ||       |         ||
                |        ||       |         ||
    +-------+   |        ||       |     +--------+     +-------+
    |       |---+        ||       +---->|        |---->|       |
    | Proxy |            ||             |  SBE3  |     | Proxy |
    |       |---+        ||       +---->|        |---->|       |
    +-------+   |        ||       |     +--------+     +-------+
                |        ||       |         ||
                |        ||       |         ||
                |    +--------+   |         ||
                |    |        |   |         ||
                +--->|  SBE2  |---+         ||
                     |        |             ||
                     +--------+             ||
                         ||                 ||
   +=====================++                 ++====================+


   In the above figure, SSP2 notifies SSP1 to reach +442079460148, send
   your SIP request to sbe3.ssp2.example.com.  SSP1 decides it prefers
   to send all requests to sbe3.ssp2.example.com via SBE2.  In order to
   do this, it assigns a trunk group to SBE2.  The trunk group, for
   example purposes, is SBE3-SSP2.  The Trunk Context is
   sbe2.ssp1.example.com.  In order for the request to be routed
   correctly from SBE2 to SSP2, there is a logical association on SBE2
   to interpret sbe3-ssp2 to sbe3.ssp2.example.com.  The trunk group and
   context are provisioned into the ENUM server, so when the Proxy (in
   this example, also the ENUM client) queries for +442079460148 it
   receives the following response:

   $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip"  "!^.*$!sip:\1;tgrp=SBE3-SSP2;
               trunk-context=sbe2.ssp1.example.com
                                   @sbe3.ssp2.example.com;user=phone!" .




Malas & Creighton        Expires April 29, 2010                 [Page 5]


Internet-Draft           Trunk Group Use in ENUM            October 2009


   If SSP1 desires SBE1 to be a fail-over solution to SBE2, then this
   would be an example response:

   $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip"  "!^.*$!sip:\1;tgrp=TG1-SBE3-SSP2;
                     trunk-context=sbe2.ssp1.example.com
                                   @sbe3.ssp2.example.com;user=phone!" .
      NAPTR 10 101 "u" "E2U+sip"  "!^.*$!sip:\1;tgrp=TG2-SBE3-SSP2;
                     trunk-context=sbe1.ssp1.example.com
                                   @sbe3.ssp2.example.com;user=phone!" .

   In the above fail-over solution a logical association to
   sbe3.ssp2.example.com would be required on both SBE1 and SBE2.

1.3.  Why Not Create a new ENUM Service Type?

   One method for identifying a trunk group in ENUM could be to define a
   new service type "trunk".  This new service type would return 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.

   An evaluation of [RFC3402], [RFC3403], and [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.

   This is illustrated in the following example of a client querying the
   server for a SIP URI available for the telephone number
   +442079460148.  The example illustrates a potential additional
   service type mechanism, where the trunk group parameters are returned
   in a new ENUM 'trunk' 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.



Malas & Creighton        Expires April 29, 2010                 [Page 6]


Internet-Draft           Trunk Group Use in ENUM            October 2009


   The following example illustrates a potential scenario indicating how
   an ENUM client MAY not ever evaluate a NAPTR with the '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@sbe3.ssp2.example.com!" .
     NAPTR 10 101 "u" "E2U+sip"  "!^.*$!sip:\1@sbe3.ssp2.example.com!" .
     NAPTR 11 100 "u" "E2U+trunk" "!^.*$!trunk:sip\1;tgrp=SSP2-SBE3;
                     trunk-context=sbe2.ssp1.example.com
                                   @sbe3.ssp2.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
   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.

1.4.  ENUM Client, Proxy, and User Agent Considerations

   It should not be assumed the originating proxy or user agent (UA),
   acting as the ENUM client, will perform an action based on the
   received trunk group information.  With this in mind, it is
   recommended that if the proxy or UA does not know how to interpret or



Malas & Creighton        Expires April 29, 2010                 [Page 7]


Internet-Draft           Trunk Group Use in ENUM            October 2009


   act on the trunk group parameters it should simply forward the URI as
   received from the ENUM server to the next downstream SIP signaling
   element.

1.5.  Acknowledgments

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

1.6.  IANA Considerations

   This memo includes no request to IANA.

1.7.  Security Considerations

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


2.  Normative References

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

   [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



Malas & Creighton        Expires April 29, 2010                 [Page 8]


Internet-Draft           Trunk Group Use in ENUM            October 2009


              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.

   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486,
              March 2009.


Authors' Addresses

   Daryl Malas
   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 April 29, 2010                 [Page 9]


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