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]