One document matched: draft-zhao-iptel-gwloc-slp-06.txt
Differences from draft-zhao-iptel-gwloc-slp-05.txt
INTERNET DRAFT Weibin Zhao
draft-zhao-iptel-gwloc-slp-06.txt Henning Schulzrinne
[Target Category: Experimental] Columbia University
February 16, 2004
Expires: August 16, 2004
Locating IP-to-Public Switched Telephone Network (PSTN)
Telephony Gateways via SLP
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes how to use the Service Location Protocol
(SLP) to locate Internet telephony gateways. It defines the
"service:iptel-gw" template for the Internet telephony gateway
service, and discusses the different usage scenarios and the
applicability of SLP for the Internet telephony gateway location.
Zhao, Schulzrinne Expires: August 16, 2004 [Page 1]
Internet Draft Gateway Location via SLP February 16, 2004
1. Introduction
In the Internet telephony networks, an administrative domain has one
or multiple location servers [RFC2871], and has numerous gateways
that link the Internet to the Public Switched Telephone Network
(PSTN). When a call arrives, a location server in the domain routes
the call to one of these gateways. Figure 1 shows the typical
scenario.
| incoming call
V
+-----------------+
+-----| Location Server |-----+
| +-----------------+ |
| | |
V V V
+----------+ +----------+ +----------+
| Gateway1 | | Gateway2 | | Gateway3 |
+----------+ +----------+ +----------+ Internet
.............|..............|..............|...............
V V V
+-----------------------------------------------+
| Public Switched Telephone Network (PSTN) |
+-----------------------------------------------+
Figure 1. Gateway Selection for Internet Telephony
The gateway selection at the location server depends on many factors,
including gateway availability, capacity, and cost for terminating a
particular call. Obtaining the up-to-date gateway information is
critical for a location server to route phone calls properly.
This document describes how to use the Service Location Protocol
(SLP) [RFC2608] for the gateway and location server interaction. It
defines the "service:iptel-gw" template for the Internet telephony
gateway service, and discusses the different usage scenarios and the
applicability of SLP for the Internet telephony gateway location.
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].
2. SLP Overview
SLP provides a scalable framework for service discovery and selection
within one administrative domain. A service is described using a set
of attributes, which is defined in the service template [RFC2609].
Zhao, Schulzrinne Expires: August 16, 2004 [Page 2]
Internet Draft Gateway Location via SLP February 16, 2004
An SLP system has three different entities: User Agent (UA), Service
Agent (SA), and Directory Agent (DA). Normally, applications are
bound to UAs and services to SAs. DAs may be deployed to cache
service registrations from SAs to enhance the system scalability.
Without DAs, a UA needs to query all SAs via multicast. If DAs are
deployed, SAs register with DAs, and UAs query DAs, both via unicast.
SLP uses both push and pull to disseminate service information. SAs
can push service registrations to DAs via unicast, or perform
notification to all UAs via multicast [RFC3082]. UAs can pull service
information from all SAs via multicast, or from a DA via unicast.
3. Using SLP for Internet Telephony Gateway Location
As a key constraint of Internet telephony is to minimize the call
setup delay, a location server SHOULD reduce the time of gateway
selection as much as possible. It is desirable that a location server
has required gateway information before a call arrives. Otherwise, it
will incur a longer call setup delay if a location server pulls
gateway information after a call has arrived. Thus, the interaction
of gateways and location servers shall use a push model: gateways
push their information to location servers.
To push gateway information to location servers, the mechanism
described in RFC 3082 [RFC3082] can be used if multicast is
supported. When multicast is not available or cannot be used for some
reasons, the mechanism described in the next section can be used.
4. Pushing Gateway Information via Unicast
To push gateway information to location servers via unicast, each
location server needs to use a dedicated SLP DA. Figure 2 shows the
architecture. The dedicated DA is a standard SLP DA, but it SHOULD
use a special scope for the "iptel-gw" service (this DA may support
other scopes if needed). The default value for this special scope is
"iptel-gw", but it could be set to some other value administratively.
Using a special scope for the "iptel-gw" service can ensure that
"service:iptel-gw" registrations are only sent to dedicated DAs at
location servers, other service registrations will not be sent to
these dedicated DAs if they only support one special scope for the
"iptel-gw" service.
Note that binding applications to DAs is not the common usage model
for SLP DAs. This usage is motivated by performance and timeliness
requirements of Internet telephony, where a location server needs to
frequently consult the gateway information to make routing decisions,
and the lookup time must be short.
Zhao, Schulzrinne Expires: August 16, 2004 [Page 3]
Internet Draft Gateway Location via SLP February 16, 2004
When multiple location servers are deployed in a domain, a gateway
may need to push its information to several location servers. By
using the SLP mesh-enhancement [RFC3528], a gateway only needs to
push its information to one location server, then the information
will be propagated automatically to other location servers. In
general, a location server may use multiple gateways, and a gateway
may serve multiple location servers.
......................... .........................
. +-------------------+ . . +-------------------+ .
. | Location Server 1 | . . | Location Server 2 | .
. +-------------------+ . . +-------------------+ .
. | . . | .
. +----------+ . . +----------+ .
. +---| SLP DA |---+ . . | SLP DA | .
. | +----------+ | . . +----------+ .
..|.........|........|... ............|.|..........
| | | | |
................| ........|....... |................| |
. +----------+ .| . +----------+ . |. +----------+ .| |
. | SLP SA |--+ . | SLP SA | . +--| SLP SA |--+ |
. +----------+ .| . +----------+ . . +----------+ . |
. | .| . | . . | . |
. +----------+ .| . +----------+ . . +----------+ . |
. | Gateway1 | .| . | Gateway2 | . . | Gateway3 | . |
. +----------+ .| . +----------+ . . +----------+ . |
................| ................ ................ |
+-------------------------------------+
Figure 2. Push Gateway Information to Location Servers via Unicast
4.1. Gateway Operations
A gateway uses an SLP SA to advertise its service. It registers its
information with location servers using the "service:iptel-gw"
template, refreshes its registration periodically, updates its
registration whenever it is needed, and de-registers its information
when its service is no longer available. A gateway discovers location
servers using standard SLP DA discovery mechanisms, including static
configuration, DHCP [RFC2610], passively listening for DAAdvert (DA
Advertisement) multicast, and actively sending the
"service:directory-agent" SrvRqst (Service Request) multicast.
4.2. Location Server Operations
A location server uses an SLP DA as its front end to accept and store
gateway registrations. Normally the location server and its front end
Zhao, Schulzrinne Expires: August 16, 2004 [Page 4]
Internet Draft Gateway Location via SLP February 16, 2004
DA are in the same machine. The location server uses an SLP UA to
issue SLP requests via LOOPBACK to the local DA (Figure 3). This
polling has a lower cost compared with a non-local UA-DA query.
When a call arrives, the location server looks up the gateway
information, and routes the call to a gateway properly. To find the
best gateway for a call, the location server can use a SrvRqst
followed by AttrRqst(s) (Attribute Request) to obtain relevant
attribute information of gateways, then it makes a choice by itself.
Note that the location server can use the Attribute List Extension
[RFC3059] in the SrvRqst to optimize the above operations.
+------------------+
| Location Server |
| | |
| UA ------ DA |
+------------------+
|
+----+
| SA |
+----+
Figure 3. Location Server and its front end SLP DA
5. Template for Internet Telephony Gateway Service
The "service:iptel-gw" template defines the attributes associated
with the Internet telephony gateway service. Please refer to RFC 2609
[RFC2609] for detailed explanation of the syntax.
Name of submitters: Weibin Zhao <zwb@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
Language of service template: en (English)
Security Considerations:
Internet telephony gateway services are likely to be paid
services, so that there could be a particular incentive to modify
somebody else's registrations. The standard SLP authentication
mechanism SHOULD be used for accepting service registrations.
Template Text:
----------------------template begins here-----------------------
template-type = iptel-gw
template-version = 1.0
Zhao, Schulzrinne Expires: August 16, 2004 [Page 5]
Internet Draft Gateway Location via SLP February 16, 2004
template-description =
This template describes the attributes supported by the Internet
telephony gateway service.
template-url-syntax =
; "service:iptel-gw://" host ":" port
; host = host from section 2.1 of RFC 2609
; port = port from section 2.1 of RFC 2609
iptel-gw-total-capacity = integer
# Total number of phone calls that can be supported by the
# gateway.
#
# Example:
# iptel-gw-total-capacity = 1024
iptel-gw-remaining-capacity = integer
# Number of phone calls that can be further supported by the
# gateway.
#
# Example:
# iptel-gw-remaining-capacity = 312
iptel-gw-prefix-list = string M L
# A list of phone number prefixes that can be reached from the
# gateway. Each phone number prefix MUST be an E.164 number
# prefix without visual separators and without the "+" prefix.
#
# Grammar:
# iptel-gw-prefix-list = prefix /
# prefix "," iptel-gw-prefix-list
# prefix = 1*DIGIT
# DIGIT = %x30-39
#
# Example:
# iptel-gw-prefix-list = 1212,4930,8610
# where 1212 --- New York, NY, USA
# 4930 --- Berlin, Germany
# 8610 --- Beijing, P.R.China
iptel-gw-cost-list = string M L
# A list of prefix-cost pairs, specifying the cost for reaching
# each phone number prefix defined in the "iptel-gw-prefix-list"
# attribute. Prefix A MUST precede prefix B if A is more specific
# than B, e.g., 1212 MUST precede 1. The last element of this
# list may omit the prefix, which represents all unspecified
# prefixes. To determine the cost for reaching a prefix, use
# longest-prefix matching.
Zhao, Schulzrinne Expires: August 16, 2004 [Page 6]
Internet Draft Gateway Location via SLP February 16, 2004
#
# The cost is given in a relative manner (the smaller the better);
# no cost unit is specified here. We assume that all gateways are
# configured to use some default unit for cost measurement, which
# implies that there is a common administrator for all gateways
# being considered. Similar to SLP, this is designed to be used in
# networks under cooperative administrative control.
#
# Grammar:
# iptel-gw-cost-list = cost-info /
# cost-info "," iptel-gw-cost-list
# cost-info = [prefix] ":" cost
# prefix = 1*DIGIT
# cost = 1*DIGIT
# DIGIT = %x30-39
#
# Example:
# iptel-gw-prefix-list = 1,49,86
# iptel-gw-cost-list = 1212:5,1:10,:20
# where the costs are as follows:
# Prefix Cost
# 1212 (New York, NY, USA) 5
# 1 (all other places in USA/Canada) 10
# 49,86 (Germany, P.R.China) 20
iptel-gw-asr-list = string M L O
# A list of prefix-ASR pairs, specifying the ASR for each phone
# number prefix defined in the "iptel-gw-prefix-list" attribute.
# This is an optional attribute. Prefix A MUST precede prefix B
# if A is more specific than B, e.g., 1212 MUST precede 1. The
# last element of this list may omit the prefix, which represents
# all unspecified prefixes. To determine the ASR for a prefix,
# use longest-prefix matching.
#
# ASR (Answer Seizure Ratio) is defined in ITU-T Recommendation
# E.411 [E411] as the percentage of the number of seizures that
# result in an answer signal over the total number of seizures
# in a specified period of time.
#
# Grammar:
# iptel-gw-asr-list = asr-info /
# asr-info "," iptel-gw-asr-list
# asr-info = [prefix] ":" asr
# prefix = 1*DIGIT
# asr = 1*DIGIT ["." 1*DIGIT]
# DIGIT = %x30-39
#
# Example:
Zhao, Schulzrinne Expires: August 16, 2004 [Page 7]
Internet Draft Gateway Location via SLP February 16, 2004
# iptel-gw-prefix-list = 1,49,86
# iptel-gw-asr-list = 1212:99.9,1:98.1,:95.8
# where the ASRs are as follows:
# Prefix ASR
# 1212 (New York, NY, USA) 99.9
# 1 (all other places in USA/Canada) 98.1
# 49,86 (Germany, P.R.China) 95.8
-----------------------template ends here------------------------
6. Discussion
In this section, we show that SLP can meet the requirements of the
Internet telephony gateway discovery.
(1) Fast: Using SLP, gateways send their registrations to location
servers in advance. During a call setup, a location server only
queries its local SLP DA to find the proper gateway.
(2) Failure Detection: Using SLP, gateway availability can be decided
in two ways. First, as each registration is a soft state, an expired
registration will be removed, which indicates the corresponding
gateway is not available. Second, a gateway can de-register its
service information with location servers.
(3) Startup Detection: Using SLP, a recovered gateway can send a new
registration to location servers to notify its availability.
(4) Capacity Knowledge: Using SLP, the capacity information is
carried in the gateway registration, as specified in the
"service:iptel-gw" service template.
(5) Secure: SLP has authentication mechanism.
(6) Routing Information: Using SLP, the routing information is
carried in the gateway registration, as specified via the "iptel-gw-
prefix-list" attribute in the "service:iptel-gw" service template.
(7) Timeliness: Using SLP, a gateway can update its service
registration whenever it is needed. A wide range of updating interval
is supported in SLP, from a few seconds to several hours.
(8) Extensible Attributes: Using SLP, new attributes for the
"service:iptel-gw" service template can be defined and added later.
(9) Efficient: Gateway registrations at location servers can be
refreshed or updated in a wide range of interval: from a few seconds
to several hours. Thus, registration traffic is modest, and is
Zhao, Schulzrinne Expires: August 16, 2004 [Page 8]
Internet Draft Gateway Location via SLP February 16, 2004
demand-driven in most cases. Also, all registrations are performed in
unicast. Furthermore, each location server accesses the gateway
information locally (on the same machine).
(10) Routing Control: Using SLP, gateway information is collected by
SLP DAs, each location server makes its own routing decision.
(11) Independent Policies: If multiple location servers exist within
one administrative domain, gateways register with all available
location servers. Using SLP, location servers can adopt different
policies, and make different routing decisions.
7. Security Considerations
Internet telephony gateway services are likely to be paid services,
so that there could be a particular incentive to modify somebody
else's registrations. The standard SLP authentication mechanism
SHOULD be used for accepting service registrations.
8. Acknowledgments
The authors would like to thank Erik Guttman, Ira McDonald and James
Kempf for their valuable comments.
9. Normative References
[RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service
location protocol, version 2", RFC 2608, June 1999.
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC 2119, March 1997.
10. Non-normative References
[RFC2871] J. Rosenberg and H. Schulzrinne, "A Framework for
Telephony Routing over IP", RFC 2871, June 2000.
[RFC2609] E. Guttman, C. Perkins and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999.
[RFC3082] J. Kempf and J. Goldschmidt, "Notification and
Subscription for SLP", RFC 3082, March 2001.
[RFC3528] W. Zhao, H. Schulzrinne and E. Guttman, "Mesh-enhanced
Service Location Protocol (mSLP)", RFC 3528, April 2003.
[RFC2610] C. Perkins and E. Guttman, "DHCP options for service
location protocol", RFC 2610, June 1999.
Zhao, Schulzrinne Expires: August 16, 2004 [Page 9]
Internet Draft Gateway Location via SLP February 16, 2004
[RFC3059] E. Guttman, "Attribute List Extension for the Service
Location Protocol", RFC 3059, February 2001.
[E411] ITU-T Recommendation E.411: "International Network Management
- Operational Guidance", Geneva, 1993.
11. Authors' Addresses
Weibin Zhao
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027-7003
Email: {zwb,hgs}@cs.columbia.edu
12. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Zhao, Schulzrinne Expires: August 16, 2004 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 03:10:38 |