Internet DRAFT - draft-gunn-ieprep-ip-telephony-gap
draft-gunn-ieprep-ip-telephony-gap
Internet Draft ETS Gap Analysis December 19th, 2003
Internet Engineering Task Force Janet P. Gunn
Internet Draft Dennis Berg
Expiration: June 19 2004 CSC
File: draft-gunn-ieprep-ip-telephony-gap-00.txt Pat McGregor
Nyquetek Inc.
Gap Analysis for Meeting
Emergency Telecommunications Service (ETS) Requirements
with DIFFSERV and MPLS in a Single IP Telephony Domain
December 19, 2003
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.
Abstract
This document presents a gap analysis for meeting ETS requirements
using DIFFSERV and MPLS with reference to one particular network
scenario: implementing Internet Telecommunications Disaster Recovery
(ETS) service in the context of IP Telephony in a private IP network
designed, engineered and managed with telephony (using DIFFSERV and
MPLS) as the dominant application.
Gunn Page 1
Internet Draft ETS Gap Analysis December 19th, 2003
Table of Contents
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 2
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Reference Network Topology . . . . . . . . . . . . . . . . . . 3
3.0 User Requirements. . . . . . . . . . . . . . . . . . . . . . . 4
4.0 Constraining Requirements. . . . . . . . . . . . . . . . . . . 5
5.0 DIFFSERV Gap Identification. . . . . . . . . . . . . . . . . . 5
6.0 MPLS Gap Identification. . . . . . . . . . . . . . . . . . . . 6
7.0 Security Considerations . . . . . . . . . . . . . . . . . . . 7
8.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9.0 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
11.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.0 Author Information . . . . . . . . . . . . . . . . . . . . . . 8
13.0 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.0 Introduction
This document presents a gap analysis for meeting ETS requirements
using DIFFSERV and MPLS with reference to one particular network
scenario: implementing Internet Telecommunications Disaster Recovery
(also known as Emergency Telecommunications Service, or ETS) service in
the context of IP Telephony in a private IP network designed,
engineered and managed with telephony (using DIFFSERV [DIFFSERV]and
MPLS[MPLS]) as the dominant application. In this particular network
scenario, the IP network serves only as a transit network, with all ETS
calls originating and terminating in the Circuit Switched Network
(CSN). This topology is referred to as "IP Bridging", or "IP in the
Middle" [IEPREP Term].
This document has the following sections:
1) Introduction
2) Reference Network Topology
3) User Requirements
4) Constraining Requirements
5) DIFFSERV Gap Identification
6) MPLS Gap Identification
7) Security Considerations
8) IANA Considerations
9) Conclusion
10)Acknowledgements
11)References
12)Author Information
Comments should be sent to Janet Gunn at jgunn6@csc.com
Gunn Page 2
Internet Draft ETS Gap Analysis December 19th, 2003
2.0 Reference Network Topology
The IP Bridging Topology is defined in [IEPREP Term] and is sometimes
known as "IP in the Middle" of two CSNs. In this topology, a CSN
phone of any type initiates (dials) a call to another CSN phone with
an IP core between the two CSNs. For purposes of this document, the IP
in the middle is a single domain, telephony-enabled, IP network (using
DIFFSERV and MPLS) without issues of technological continuity and
interfacing that arise with multiple domains.
This topology should simplistically look like this:
----------------->+<--------IP-Based Telephony Network------>+<--------
-----
--------------+ +----+ +----+ +----------
| | | | | |
STP.....|....|.SG | | SG.|....|....STP
: | | : | | : | | :
: | | : | +--------------+ | : | | :
: | | MGC| | | | MGC| | :
: | | : | | | | : | | :
: | | : | | | | : | | :
AT ------->| MG |------LSR -----LSR----->| MG |--------> AT
| | | | | | | |
| +----+ | | +----+ |
-----------+ +--------------+ +-----------
Exploded "IP Bridging" Topology
This diagram is intended to portray a possible CSN carrier that has
introduced an IP transport island into his network, or, perhaps more
generally, a CSN Local Exchange Carrier (LEC) transiting an IP
Interexchange Carrier to another CSN LEC. Note that although the
topology shows the SG connected directly to the MGC and the MGC
connected directly to the MG, these connections should be viewed as
logical connections, physically formed by LSPs through the LSRs, with
the SG, MGC, and MG all actually connected to the LSRs.
The baseline telephony application design for this topology is assumed
to be bearer traffic from AT to MG and MG to AT via conventional TDM
trunks and from MG to LSR to LSR to MG via E-LSPs providing EF PHB
supporting RTP media exchange between the MGs.
The reference topology is assumed implemented for voice traffic using
DIFFSERV
and MPLS.
Gunn Page 3
Internet Draft ETS Gap Analysis December 19th, 2003
3.0 User Requirements
Requirements for generic ETS are presented in [IEPREP Rqmts] and
augmented with telephony-specific requirements in [IEPREP IP Tel
Rqmts]. Requirements for specific providers will be specified in
individual SLAs. ETS SLAs require performance to the extent possible,
even under circumstances of extraordinary demand and/or outages such as
caused by Acts of God and War for which non-ETS SLAs generally take
exception.
Some providers of the single-domain telephony service addressed in this
paper may be able to meet all SLA performance metrics for telephony ETS
calls (e.g., low probability of blocking and toll quality voice)
without a distinct service for ETS traffic. An example would be a
single-domain provider whose sum of domain access capacities is less
than the capacity of every possible path over which concurrent traffic
might be routed.
Other providers may be in a situation where their network can become
congested (and SLA ETS performance compromised), either as a result of
extraordinary access demand, combined with statistically rare
burstiness, exceeding transport capacity, or as a result of transport
capacity being reduced by outages, or by a combination of extraordinary
demand and outages. For these providers to meet SLA ETS performance
objectives during severe network stress, mechanisms must be provided
by which ETS traffic can be recognized and afforded some form of
treatment that enables its performance objectives to be met. For
convenience, we refer this as an SLA requirement to ensure ETS.
By addressing the signaling requirements at the application layer, ETS
traffic can be recognized at the application layer and resources under
application control can be managed to ensure their role in ETS, i.e., a
low probability of blocking may be achieved at the application layer by
Call Access Control. Although this is necessary, it is not sufficient
if the lower layers do not have means of supporting such allocation on
a sustained (i.e. duration of the call) basis. In this context,
"allocation" may be viewed as any techniques that ensure ETS traffic
receives the resources necessary to achieve its SLA performance
specifications.
The gap analysis presented here addresses the need for certain single-
domain telephony bridging providers to be able to support ETS SLAs to
provide:
High Probability Toll-Quality Voice - ETS calls must be given adequate
resources through the network to ensure a high probability that their
packets suffer loss, delay, and jitter consistent with achieving toll-
quality voice even when network congestion and / or damage are severe.
Gunn Page 4
Internet Draft ETS Gap Analysis December 19th, 2003
It is recognized that the SLA requirements must be subject to physical
connectivity survival and capacity limitations, and that ETS traffic
may be limited by the provider in terms of its absolute and/or relative
utilization of the total available capacity.
Sessions identified as ETS could be processed as normal traffic along
with all non-emergency traffic when sufficient network bandwidth and
resources are available.
4.0 Constraining Requirements
Besides the relevant requirements from IEPREP documents, and the user
requirements above, the following general requirements are proposed to
bear upon the gap analysis:
REQ-1) Whether or not ETS calls are being served, the impact on non-ETS
calls SHOULD be minimized, consistent with providing the ETS service.
REQ-2) In some networks, depending on the topology and overall
capacity, the service MAY impose a limit on the resources that can be
used by ETS calls when there are non-ETS calls competing for those
resources.
REQ-3) Whether or not ETS calls are being served, the impact of the ETS
service on network management and administration SHOULD be minimized,
consistent with providing the ETS service.
REQ-4) The additional development (by vendors) to support the ETS
service SHOULD be minimized, consistent with providing the ETS service.
As a consequence of REQ-4, identifying new labels and parameter values
for existing protocols is preferable to inventing new protocols or
completely new parameters, where possible.
5.0 DIFFSERV Gap Identification
For the reference network and service scenario, the need in DIFFSERV is
for a way to ensure service to ETS traffic during conditions of network
traffic saturation. [IEPREP Frame] has suggested the approach of using
AF instead of EF for ETS traffic to reduce the dropping probability.
This approach, however, does not provide bounds on delay and jitter, so
it does not appear to be acceptable in meeting the requirement for
toll-quality voice.
[IEPREP Frame] has alternatively suggested employing an additional Per
Hop Behavior (PHB) for ETS traffic, without specifying the behavior.
Using a second instance of EF, with a strict priority queue, might
reduce the dropping probability, and reduce the delay and jitter, for
ETS traffic. This approach, however appears to violate REQ-1 to
Gunn Page 5
Internet Draft ETS Gap Analysis December 19th, 2003
minimize the impact on non-ETS VoIP traffic. As described in the
Appendix to RFC 3246 [DIFFSERV EF], the bounds on delay for the (lower
priority) non-ETS EF traffic would become large, or even unbounded,
thereby undermining QoS for the non-ETS EF traffic.
The Appendix to RFC 3246 [DIFFSERV EF] points out that multiple
instances of EF with a WFQ-like scheduler could overcome the
limitations of a strict priority queue by delivering delay bounds
similar to a single instance of EF. Using a second instance of EF,
then, with some form of Fair Weighted Queuing that recognizes ETS
traffic as distinct, seems to be a viable approach. However,
employing a second instance of EF would require two distinct EF
DIFFSERV codepoints.
Based upon this analysis there appears to be a gap in DIFFSERV in
respect to providing the ETS service in the reference scenario.
6.0 MPLS Gap Identification
For the reference network and service scenario, the need in MPLS [MPLS]
is for a way to support DIFFSEV [MPLS DIFF] to ensure ETS telephony.
For MPLS support of DIFSERV in the reference network and service, two
basic approaches appear to be:
1) Define a separate MPLS codepoint to correlate with a
ETS DIFFSERV codepoint
2) Implement a separate set of E-LSPs for the ETS traffic uniquely
distinguished in DIFFSERV.
It is recognized that MPLS LSPs [MPLS] have very limited resources for
traffic differentiation, and the first (1) approach's allocating a
limited traffic differentiation resources for the nominally rare, but
occasionally heavy ETS traffic may be viewed as wasteful. However, the
alternative approach (2) of creating a separate ETS topology of LSPs
presents significant difficulties because of the ubiquitous requirement
for ETS support coupled with its rare use, leading to significant
maintenance and operating challenges. Thus approach (2) seems to
contravene REQ-3, which cautions that the impact of ETS on network
management and administration should be minimized. Complying with REQ-
3 implies that the ETS service should not be dependant on the
maintenance and management of a distinct "shadow network" or VPN.
Both candidate approaches have advantages and disadvantages. Approach
(1) satisfies REQ-3, but exposes a gap in that there is no MPLS
codepoint identified for the additional ETS DIFFSERV codepoint
distinguishing ETS packets within an MPLS path also supporting non-ETS
packets.
Gunn Page 6
Internet Draft ETS Gap Analysis December 19th, 2003
7.0 Security Considerations
There are two primary concerns:
- Authorization/authentication of voice traffic which is entitled to
ETS-treatment. In the reference IP Bridging topology, this
authentication and authorization takes place in the CSN. The
security of this authorization and authentication in the IP
network is a general IP Telephony security issue, and outside the
scope of his paper.
- Potential for unauthorized use of ETS, and for DoS or DDoS
attacks. This document recognizes these issues, but does not
address them because they are out of scope for a gap analysis.
8.0 IANA Considerations
There are no IANA considerations addressed in this document. The
alleviation of some of the gaps identified may involve IANA
considerations.
9.0 Conclusion
From the perspective of the reference network topology and service
there appear to be gaps in both DIFFSERV and MPLS. In their current
form they cannot provide an increased probability that ETS calls will
receive a satisfactory (i.e., non-degraded) quality of service in a
stressed network environment while meeting REQ-1, REQ-2, REQ-3 and
REQ-4.
10.0 Acknowledgements
The authors would like to acknowledge the helpful comments, opinions,
and clarifications of Richard Kaczmarek, as well as those comments
received from the IEPREP mailing list.
11.0 References
Normative
[DIFFSERV] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
[DIFFSERV EF] Davie, B., Charny, A., Bennett, J.C.R., K. Benson, Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., Stiliadis, D., "An
Expedited Forwarding PHB (Per-Hop Behavior)" RFC 3246, March 2002
[IEPREP Term] Polk, J., "Internet Emergency Preparedness (IEPREP)
Telephony Topology Terminology", RFC 3523, April 2003.
Gunn Page 7
Internet Draft ETS Gap Analysis December 19th, 2003
[MPLS] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[MPLS DIFF] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Services", RFC 3270, May
2002.
Non-Normative
[IEPREP Frame] Carlberg, K., Brown, I., Beard, C., "Framework for
Supporting ETS in IP Telephony",draft-ietf-ieprep-framework-07.txt , Internet-Draft,
December, 2003 .
[IEPREP Rqmts] Carlberg, K., Atkinson, R., "General Requirements for
Emergency Telecommunications Service", draft-ietf-ieprep-ets-general-04.txt, Internet-
Draft, August, 2003.
[IEPREP IP Tel Rqmts] Carlberg, K., Atkinson, R., "IP Telephony
Requirements for Emergency Telecommunications Service", draft-ietf-ieprep-ets-telephony-07.txt, Internet Draft, November, 2003.
12.0 Author Information
Pat McGregor
Nyquetek Inc
8397 Piping Rock
Millersville, MD 21108 U.S.A.
Email: pat_mcgregor@msn.com
Phone: 410-703-4486
Dennis Berg
CSC
15000 Conference Center Dr
Chantilly, VA
Email: Dberg3@CSC.com
Phone: 703-818-4608
Janet Gunn
CSC
15000 Conference Center Dr
Chantilly, VA
Email: JGunn6@CSC.com
Phone: 703-818-4725
Gunn Page 8
Internet Draft ETS Gap Analysis December 19th, 2003
13.0 Acronyms
The following acronyms are exploded for clarity:
AT = Access Tandem
CSN = Circuit Switched Network
EF = Expedited Forwarding
E-LSP = EXP-inferred-PSC LSPs
ETS = Emergency Telecommunications Service
EXP = field in MPLS label
LSP = Label Switched Path
LSR = Label Switching Router
MG = Media Gateway
MGC = Media Gateway Controller
MPLS = Multi-Protocol Label Switching
PHB = Per Hop Behavior
PSC = PHB Scheduling Class
SG = Signaling Gateway
STP = Signal Transfer Point
TDM = Time Division Multiplexing
"Copyright (C) The Internet Society (December 19, 2003). 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.
Gunn Page 9
Internet Draft ETS Gap Analysis December 19th, 2003
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."
The Expiration date for this Internet Draft is:
April 19, 2004
Gunn Page 10
