4.1.4. RTP
The Real-Time Transport Protocol (RTP) provides end-to-end delivery
services for data with real-time characteristics. The type of data
is generally in the form of audio or video type applications, and is
frequently interactive in nature. RTP is typically run over UDP and
has been designed with a fixed header that identifies a specific type
of payload representing a specific form of application media. The
designers of RTP also assumed an underlying network providing best
effort service. As such, RTP does not provide any mechanism to
ensure timely delivery or provide other QoS guarantees. However, the
emergence of applications like IP telephony, as well as new service
models, present new environments where RTP traffic may be forwarded
over networks that support better than best effort service. Hence,
the original scope and target environment for RTP has expanded to
include networks providing services other than best effort.
In 4.1.2, we discussed one means of marking a data packet for
emergencies under the context of the diff-serv architecture.
However, we also pointed out that diff-serv markings for specific
PHBs are not globally unique, and may be arbitrarily removed or even
changed by intermediary nodes or domains. Hence, with respect to
emergency related data packets, we are still missing an in-band
marking in a data packet that stays constant on an end-to-end basis.
There are three choices in defining a persistent marking of data
packets and thus avoiding the transitory marking of diff-serv code
points. One can propose a new PHB dedicated for emergency type
traffic as discussed in 4.1.2. One can propose a specification of a
new shim layer protocol at some location above IP. Or, one can add a
new specification to an existing application layer protocol. The
first two cases are probably the "cleanest" architecturally, but they
are long term efforts that may not come to pass because of a limited
number of diff-serv code points and the contention that yet another
shim layer will make the IP stack too large. The third case, placing
a marking in an application layer packet, also has drawbacks; the key
weakness being the specification of a marking on a per-application
basis.
Discussions have been held in the Audio/Visual Transport (AVT)
working group on augmenting RTP so that it can carry a marking that
distinguishes emergency-related traffic from that which is not.
Specifically, these discussions centered on defining a new extension
that contains a "classifier" field indicating the condition
associated with the packet (e.g., authorized-emergency, emergency,
normal) [26]. The rationale behind this idea was that focusing on
RTP would allow one to rely on a point of aggregation that would
apply to all payloads that it encapsulates. However, the AVT group
has expressed a rough consensus that placing an additional classifier
state in the RTP header to denote the importance of one flow over
another is not an approach they wish to advance. Objections ranging
from relying on SIP to convey the importance of a flow, to the
possibility of adversely affecting header compression, were
expressed. There was also the general feeling that the extension
header for RTP that acts as a signal should not be used.
4.1.5. GCP/H.248
The Gateway Control Protocol (GCP) [21] defines the interaction
between a media gateway and a media gateway controller. [21] is
viewed as an updated version of common text with ITU-T Recommendation
H.248 [41] and is a result of applying the changes of RFC 2886
(Megaco Errata) [43] to the text of RFC 2885 (Megaco Protocol version
0.8) [42].
In [21], the protocol specifies a Priority and Emergency field for a
context attribute and descriptor. The Emergency is an optional
boolean (True or False) condition. The Priority value, which ranges
from 0 through 15, specifies the precedence handling for a context.
The protocol does not specify individual values for priority. We
also do not recommend the definition of a well known value for the
GCP priority as this is out of scope of this document. Any values
set should be a function of any SLAs that have been established
regarding the handling of emergency traffic.
4.2. Policy
One of the objectives listed in Section 3 above is to treat ETS
signaling, and related data traffic, as non-preemptive in nature.
Further, this treatment is to be the default mode of operation or
service. This is in recognition that existing regulations or laws of
certain countries governing the establishment of SLAs may not allow
preemptive actions (e.g., dropping existing telephony flows). On the
other hand, the laws and regulations of other countries influencing
the specification of SLA(s) may allow preemption, or even require its
existence. Given this disparity, we rely on local policy to
determine the degree by which emergency-related traffic affects
existing traffic load of a given network or ISP. Important note: we
reiterate our earlier comment that laws and regulations are generally
outside the scope of the IETF and its specification of designs and
protocols. However, these constraints can be used as a guide in
producing a baseline capability to be supported; in our case, a
default policy for non-preemptive call establishment of ETS signaling
and data.
Policy can be in the form of static information embedded in various
components (e.g., SIP servers or bandwidth brokers), or it can be
realized and supported via COPS with respect to allocation of a
domain’s resources [16]. There is no requirement as to how policy is
accomplished. Instead, if a domain follows actions outside of the
default non-preemptive action of ETS-related communication, then we
stipulate that some type of policy mechanism be in place to satisfy
the local policies of an SLA established for ETS-type traffic.
4.3. Traffic Engineering
In those cases where a network operates under the constraints of
SLAs, one or more of which pertains to ETS-based traffic, it can be
expected that some form of traffic engineering is applied to the
operation of the network. We make no recommendations as to which
type of traffic engineering mechanism is used, but that such a system
exists in some form and can distinguish and support ETS signaling
and/or data traffic. We recommend a review of [32] by clients and
prospective providers of ETS service that gives an overview and a set
of principles of Internet traffic engineering.
MPLS is generally the first protocol that comes to mind when the
subject of traffic engineering is brought up. This notion is
heightened concerning the subject of IP telephony because of MPLS’s
ability to permit a quasi-circuit switching capability to be
superimposed on the current Internet routing model [30].
However, having cited MPLS, we need to stress that it is an
intradomain protocol, and so may or may not exist within a given ISP.
Other forms of traffic engineering, such as weighted OSPF, may be the
mechanism of choice by an ISP.
As a counter example of using a specific protocol to achieve traffic
engineering, [37] presents an example of one ISP relying on a high
amount of overprovisioning within its core to satisfy potentially
dramatic spikes or bursts of traffic load. In this approach, any
configuring of queues for specific customers (neighbors) to support
the target QoS is done on the egress edge of the transit network.
Note: As a point of reference, existing SLAs established by the NCS
for GETS service tend to focus on a loosely defined maximum
allocation of, for example, 1% to 10% of calls allowed to be
established through a given LEC using HPC. It is expected, and
encouraged, that ETS related SLAs of ISPs will be limited with
respect to the amount of traffic distinguished as being emergency
related and initiated by an authorized user.
4.4. Security
This section provides a brief overview of the security issues raised
by ETS support.
4.4.1. Denial of Service
Any network mechanism that enables a higher level of priority for a
specific set of flows could be abused to enhance the effectiveness of
denial of service (DoS) attacks. Priority would magnify the effects
of attack traffic on bandwidth availability in lower-capacity links,
and increase the likelihood of it reaching its target(s). An attack
could also tie up resources such as circuits in a PSTN gateway.
Any provider deploying a priority mechanism (such as the QoS systems
described in Section 4.1) must therefore carefully apply the
associated access controls and security mechanisms. For example, the
priority level for traffic originating from an unauthorized part of a
network or ingress point should be reset to normal. Users must also
be authenticated before being allowed to use a priority service (see
Section 4.4.2). However, this authentication process should be
lightweight to minimise opportunities for denial of service attacks
on the authentication service itself, and ideally should include its
own anti-DoS mechanisms. Other security mechanisms may impose an
overhead that should be carefully considered to avoid creating other
opportunities for DoS attacks.
As mentioned in Section 4.3, SLAs for ETS facilities often contain
maximum limits on the level of ETS traffic that should be prioritised
in a particular network (say 1% of the maximum network capacity).
This should also be the case in IP networks to again reduce the level
of resources that a denial of service attack can consume.
As of this writing, a typical inter-provider IP link uses 1 Gbps
Ethernet, OC-48 SONET/SDH, or some similar or faster technology.
Also, as of this writing, it is not practical to deploy per-IP packet
cryptographic authentication on such inter-provider links, although
such authentication might well be needed to provide assurance of IP-
layer label integrity in the inter-provider scenario.
While Moore’s Law will speed up cryptographic authentication, it is
unclear whether that is helpful because the speed of the typical
inter-domain link is also increasing rapidly.
4.4.2. User Authorization
To prevent theft of service and reduce the opportunities for denial
of service attacks, it is essential that service providers properly
verify the authorization of a specific traffic flow before providing
it with ETS facilities.
Where an ETS call is carried from PSTN to PSTN via one telephony
carrier’s backbone IP network, very little IP-specific user
authorization support is required. The user authenticates itself to
the PSTN as usual -- for example, using a PIN in the US GETS. The
gateway from the PSTN connection into the backbone IP network must be
able to signal that the flow has an ETS label. Conversely, the
gateway back into the PSTN must similarly signal the call’s label. A
secure link between the gateways may be set up using IPSec or SIP
security functionality to protect the integrity of the signaling
information against attackers who have gained access to the backbone
network, and to prevent such attackers from placing ETS calls using
the egress PSTN gateway. If the destination of a call is an IP
device, the signaling should be protected directly between the IP
ingress gateway and the end device.
When ETS priority is being provided to a flow within one domain, that
network must use the security features of the priority mechanism
being deployed to ensure that the flow has originated from an
authorized user or process.
The access network may authorize ETS traffic over a link as part of
its user authentication procedures. These procedures may occur at
the link, network, or higher layers, but are at the discretion of a
single domain network. That network must decide how often it should
update its list of authorized ETS users based on the bounds it is
prepared to accept on traffic from recently-revoked users.
If ETS support moves from intra-domain PSTN and IP networks to
inter-domain end-to-end IP, verifying the authorization of a given
flow becomes more complex. The user’s access network must verify a
user’s ETS authorization if network-layer priority is to be provided
at that point.
Administrative domains that agree to exchange ETS traffic must have
the means to securely signal to each other a given flow’s ETS status.
They may use physical link security combined with traffic
conditioning measures to limit the amount of ETS traffic that may
pass between the two domains. This agreement must require the
originating network to take responsibility for ensuring that only
authorized traffic is marked with ETS priority, but the recipient
network cannot rely on this happening with 100% reliability. Both
domains should perform conditioning to prevent the propagation of
theft and denial of service attacks. Note that administrative
domains that agree to exchange ETS traffic must deploy facilities
that perform these conditioning and security services at every point
at which they interconnect with one another.
Processes using application-layer protocols, such as SIP, should use
the security functionality in those protocols to verify the
authorization of a session before allowing it to use ETS mechanisms.
4.4.3. Confidentiality and Integrity
When ETS communications are being used to respond to a deliberate
attack, it is important that they cannot be altered or intercepted to
worsen the situation -- for example, by changing the orders to first
responders such as firefighters, or by using knowledge of the
emergency response to cause further damage.
The integrity and confidentiality of such communications should
therefore be protected as far as possible using end-to-end security
protocols such as IPSec or the security functionality in SIP and SRTP
[39]. Where communications involve other types of networks such as
the PSTN, the IP side should be protected and any security
functionality available in the other network should be used.
4.5. Alternate Path Routing
This subject involves the ability to discover and use a different
path to route IP telephony traffic around congestion points, and thus
avoid them. Ideally, the discovery process would be accomplished in
an expedient manner (possibly even a priori to the need of its
existence). At this level, we make no assumptions as to how the
alternate path is accomplished, or even at which layer it is achieved
-- e.g., the network versus the application layer. But this kind of
capability, at least in a minimal form, would help contribute to
increasing the probability of ETS call completion by making use of
noncongested alternate paths. We use the term "minimal form" to
emphasize the fact that care must be taken in how the system provides
alternate paths so that it does not significantly contribute to the
congestion that is to be avoided (e.g., via excess control/discovery
messages).
Routing protocols at the IP network layer, such as BGP and OSPF,
contain mechanisms for determining link failure between routing
peers. The discovery of this failure automatically causes
information to be propagated to other routers. The form of this
information, the extent of its propagation, and the convergence time
in determining new routes is dependent on the routing protocol in
use. In the example of OSPF’s Equal Cost Multiple Path (ECMP), the
impact of link failure is minimized because of pre-existing alternate
paths to a destination.
At the time this document was written, we can identify two additional
areas in the IETF that can be helpful in providing alternate paths
for the specific case of call signaling. The first is [9], which is
focused on network layer routing and describes a framework for
enhancements to the LDP specification of MPLS to help achieve fault
tolerance. This, in itself, does not provide alternate path routing,
but rather helps minimize loss in intradomain connectivity when MPLS
is used within a domain.
The second effort comes from the IP Telephony working group and
involves Telephony Routing over IP (TRIP). To date, a framework
document [17] has been published as an RFC that describes the
discovery and exchange of IP telephony gateway routing tables between
providers. The TRIP protocol [20] specifies application level
telephony routing regardless of the signaling protocol being used
(e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises
reachability and attributes of destinations. In its current form,
several attributes have already been defined, such as LocalPreference
and MultiExitDisc. Additional attributes can be registered with
IANA.
Inter-domain routing is not an area that should be considered in
terms of additional alternate path routing support for ETS. The
Border Gateway Protocol is currently strained in meeting its existing
requirements, and thus adding additional features that would generate
an increase in advertised routes will not be well received by the
IETF. Refer to [38] for a commentary on Inter-Domain routing.
4.6. End-to-End Fault Tolerance
This topic involves work that has been done in trying to compensate
for lossy networks providing best effort service. In particular, we
focus on the use of a) Forward Error Correction (FEC), and b)
redundant transmissions that can be used to compensate for lost data
packets. (Note that our aim is fault tolerance, as opposed to an
expectation of always achieving it.)
In the former case, additional FEC data packets are constructed from
a set of original data packets and inserted into the end-to-end
stream. Depending on the algorithm used, these FEC packets can
reconstruct one or more of the original set that were lost by the
network. An example may be in the form of a 10:3 ratio, in which 10
original packets are used to generate three additional FEC packets.
Thus, if the network loses 30% of packets or less, then the FEC
scheme will be able to compensate for that loss. The drawback to
this approach is that, to compensate for the loss, a steady state
increase in offered load has been injected into the network. This
makes an argument that the act of protection against loss has
contributed to additional pressures leading to congestion, which in
turn helps trigger packet loss. In addition, by using a ratio of
10:3, the source (or some proxy) must "hold" all 10 packets in order
to construct the three FEC packets. This contributes to the end-to-
end delay of the packets, as well as minor bursts of load, in
addition to changes in jitter.
The other form of fault tolerance we discuss involves the use of
redundant transmissions. By this we mean the case in which an
original data packet is followed by one or more redundant packets.
At first glance, this would appear to be even less friendly to the
network than that of adding FEC packets. However, the encodings of
the redundant packets can be of a different type (or even transcoded
into a lower quality) that produce redundant data packets that are
significantly smaller than the original packet.
Two RFCs [22, 23] have been produced that define RTP payloads for FEC
and redundant audio data. An implementation example of a redundant
audio application can be found in [13]. We note that both FEC and
redundant transmissions can be viewed as rather specific, and to a
degree tangential, solutions regarding packet loss and emergency
communications. Hence, these topics are placed under the category of
value-added objectives.
5. Key Scenarios
There are various scenarios in which IP telephony can be realized,
each of which can imply a unique set of functional requirements that
may include just a subset of those listed above. We acknowledge that
a scenario may exist whose functional requirements are not listed
above. Our intention is not to consider every possible scenario by
which support for emergency related IP telephony can be realized.
Rather, we narrow our scope using a single guideline; we assume there
is a signaling and data interaction between the PSTN and the IP
network with respect to supporting emergency-related telephony
traffic. We stress that this does not preclude an IP-only end-to-end
model, but rather the inclusion of the PSTN expands the problem space
and includes the current dominant form of voice communication.
Note: as stated in Section 1.2, [32] provides a more extensive set of
scenarios in which IP telephony can be deployed. Our selected set
below is only meant to provide a couple of examples of how the
protocols and capabilities presented in Section 3 can play a role.
5.1. Single IP Administrative Domain
This scenario is a direct reflection of the evolution of the PSTN.
Specifically, we refer to the case in which data networks have
emerged in various degrees as a backbone infrastructure connecting
PSTN switches at its edges. This scenario represents a single
isolated IP administrative domain that has no directly adjacent IP
domains connected to it. We show an example of this scenario below
in Figure 1. In this example, we show two types of telephony
carriers. One is the legacy carrier, whose infrastructure retains
the classic switching architecture attributed to the PSTN. The other
is the next generation carrier, which uses a data network (e.g., IP)
as its core infrastructure, and Signaling Gateways at its edges.
These gateways "speak" SS7 externally with peering carriers, and
another protocol (e.g., SIP) internally, which rides on top of the IP
infrastructure.
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * ISUP * *
SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
* * (SS7) * (SIP) * (SS7) * (SIP) *
******* *************** **************
SW - Telco Switch, SG - Signaling Gateway
Figure 1
The significant aspect of this scenario is that all the resources f
each IP "island" falls within a given administrative authority.
Hence, there is not a problem in retaining PSTN type QoS for voice
traffic (data and signaling) exiting the IP network. Thus, the need
for support of mechanisms like diff-serv in the presence of
overprovisioning, and an expansion of the defined set of Per-Hop
Behaviors, is reduced under this scenario.
Another function that has little or no importance within the closed
IP environment of Figure 1 is that of IP security. The fact that
each administrative domain peers with each other as part of the PSTN,
means that existing security, in the form of Personal Identification
Number (PIN) authentication (under the context of telephony
infrastructure protection), is the default scope of security. We do
not claim that the reliance on a PIN-based security system is highly
secure or even desirable. But, we use this system as a default
mechanism in order to avoid placing additional requirements on
existing authorized emergency telephony systems.
5.2. Multiple IP Administrative Domains
We view the scenario of multiple IP administrative domains as a
superset of the previous scenario. Specifically, we retain the
notion that the IP telephony system peers with the existing PSTN. In
addition, segments (i.e., portions of the Internet) may exchange
signaling with other IP administrative domains via non-PSTN signaling
protocols like SIP.
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *