draft-ietf-ieprep-framework-01.txt   draft-ietf-ieprep-framework-02.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT Ian Brown INTERNET DRAFT Ian Brown
May 14, 2002 UCL Jun 24, 2002 UCL
Framework for Supporting IEPS in IP Telephony Framework for Supporting IEPS in IP Telephony
<draft-ietf-ieprep-framework-01.txt> <draft-ietf-ieprep-framework-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 16 skipping to change at page 3, line 16
it. it.
Beyond the introduction of new services, the continued pace of addi- Beyond the introduction of new services, the continued pace of addi-
tional traffic load experienced by ISPs over the years has continued tional traffic load experienced by ISPs over the years has continued
to place a high importance for intra-domain traffic engineering. The to place a high importance for intra-domain traffic engineering. The
explosion of IETF contributions, in the form of drafts and RFCs pro- explosion of IETF contributions, in the form of drafts and RFCs pro-
duced in the area of Multi Protocol Label Switching (MPLS), exempli- duced in the area of Multi Protocol Label Switching (MPLS), exempli-
fies the interest in versatile and manageable mechanisms for intra- fies the interest in versatile and manageable mechanisms for intra-
domain traffic engineering. One interesting observation is the work domain traffic engineering. One interesting observation is the work
involved in supporting QoS related traffic engineering. Specifically, involved in supporting QoS related traffic engineering. Specifically,
we refer to the work in progress discussion of Proposed MPLS/DiffServ we refer to MPLS support of differentiated services [9], and the on-
Traffic Engineering Class Types [9], and the inclusion of fault going work in the inclusion of fault tolerance [10]. This latter
tolerance [10]. This latter item can be viewed as being similar to item can be viewed as an example that is similar to "crank-back" (or
"crank-back", a term used to describe the means by which the Public "auto-rerouting"), a term used to describe the means by which the
Switched Telephone Network (PSTN) routes around congested switches. Public Switched Telephone Network (PSTN) routes around congested
switches.
1.1. Emergency Related Data 1.1. Emergency Related Data
The evolution of the IP service model architecture has traditionally The evolution of the IP service model architecture has traditionally
centered on the type of application protocols used over a network. centered on the type of application protocols used over a network.
By this we mean that the distinction, and possible bounds on QoS, By this we mean that the distinction, and possible bounds on QoS,
usually centers on the type of application (e.g., audio video tools) usually centers on the type of application (e.g., audio video tools)
that is being referred to. that is being referred to.
While protocols like SMTP [11] and SIP [12] have embedded fields While protocols like SMTP [11] and SIP [12] have embedded fields
skipping to change at page 4, line 50 skipping to change at page 4, line 51
will provide further priority by queuing the call for the next avail- will provide further priority by queuing the call for the next avail-
able circuit.  able circuit. 
The procedure for a user (i.e., a person) establishing a GETS call is The procedure for a user (i.e., a person) establishing a GETS call is
as follows: as follows:
1) Dial a non-geographical area code number: 710-XXX-XXXX 1) Dial a non-geographical area code number: 710-XXX-XXXX
2) Dial a PIN used to authenticate the call 2) Dial a PIN used to authenticate the call
3) Dial the actual destination number to be reached 3) Dial the actual destination number to be reached
In conjunction with the above, the source LEC (where the call ori- In conjunction with the above, the source LEC (where the call
ginated) attempts to establish the call through an IXC. This is done originated) attempts to establish the call through an IXC. This is
even if the destination number is within the LEC itself. If the IXC done even if the destination number is within the LEC itself. If the
cannot forward the call to the destination LEC, then the source LEC IXC cannot forward the call to the destination LEC, then the source
attempts to route the call through an alternate IXC. If alternate LEC attempts to route the call through an alternate IXC. If alter-
IXCs cannot help establish the call, then a busy signal is finally nate IXCs cannot help establish the call, then a busy signal is
returned to the user. Otherwise, the call is completed and retains finally returned to the user. Otherwise, the call is completed and
the same quality of service as all other telephone calls. retains the same quality of service as all other telephone calls.
The HPC component of GETS is not ubiquitously supported by the U.S. The HPC component of GETS is not ubiquitously supported by the U.S.
PSTN. The only expectation is that the 710 area code is recognized PSTN. The only expectation is that the 710 area code is recognized
by all carriers. Additional support is conditional and dependent by all carriers. Additional support is conditional and dependent
upon the equivalent Service Level Agreements (SLA) established upon the equivalent Service Level Agreements (SLA) established
between the U.S. Government and various telco carriers to support between the U.S. Government and various telco carriers to support
GETS. Thus, the default end-to-end service for establishing a GETS GETS. Thus, the default end-to-end service for establishing a GETS
call can be roughly viewed as best effort and associated with the call can be roughly viewed as best effort and associated with the
same priority as calls from the general public. same priority as calls from the general public.
skipping to change at page 5, line 49 skipping to change at page 6, line 5
The scope of this document centers on the near and mid-term support The scope of this document centers on the near and mid-term support
of IEPS within the context of IP telephony, though not necessarily of IEPS within the context of IP telephony, though not necessarily
Voice over IP. We make a distinction between these two by treating Voice over IP. We make a distinction between these two by treating
IP telephony as a subset of VoIP, where in the former case we assume IP telephony as a subset of VoIP, where in the former case we assume
some form of application layer signaling is used to explicitly estab- some form of application layer signaling is used to explicitly estab-
lish and maintain voice data traffic. This explicit signaling capa- lish and maintain voice data traffic. This explicit signaling capa-
bility provides the hooks from which VoIP traffic can be bridged to bility provides the hooks from which VoIP traffic can be bridged to
the PSTN. the PSTN.
An example of this distinction is when the Redundant Audio Tool (RAT) An example of this distinction is when the Robust Audio Tool (RAT)
[14] begins sending VoIP packets to a unicast (or multicast) destina- [14] begins sending VoIP packets to a unicast (or multicast) destina-
tion. RAT does not use explicit signaling like SIP to establish an tion. RAT does not use explicit signaling like SIP to establish an
end-to-end call between two users. It simply sends data packets to end-to-end call between two users. It simply sends data packets to
the target destination. On the other hand, "SIP phones" are host the target destination. On the other hand, "SIP phones" are host
devices that use a signaling protocol to establish a call signal devices that use a signaling protocol to establish a call signal
before sending data towards the destination. before sending data towards the destination.
One other aspect we should probably assume exists with IP Telephony One other aspect we should probably assume exists with IP Telephony
is an association of a target level of QoS per session or flow. [31] is an association of a target level of QoS per session or flow. [31]
makes an arguement that there is a maximum packet loss and delay for makes an arguement that there is a maximum packet loss and delay for
skipping to change at page 11, line 18 skipping to change at page 11, line 18
focused on network layer routing and describes enhancements to the focused on network layer routing and describes enhancements to the
LDP specification of MPLS to help achieve fault tolerance. This in LDP specification of MPLS to help achieve fault tolerance. This in
itself does not provide alternate path routing, but rather helps itself does not provide alternate path routing, but rather helps
minimize loss in intradomain connectivity when MPLS is used within a minimize loss in intradomain connectivity when MPLS is used within a
domain. domain.
The second effort comes from the IP Telephony working group and The second effort comes from the IP Telephony working group and
involves Telephony Routing over IP (TRIP). To date, a framework involves Telephony Routing over IP (TRIP). To date, a framework
document [19] has been published as an RFC which describes the document [19] has been published as an RFC which describes the
discovery and exchange of IP telephony gateway routing tables between discovery and exchange of IP telephony gateway routing tables between
providers. The TRIP protocol [22], a supplemental work in progress, providers. The TRIP protocol [22] specifies application level
specifies application level telephony routing regardless of the sig- telephony routing regardless of the signaling protocol being used
naling protocol being used (e.g., SIP or H.323). TRIP is modeled (e.g., SIP or H.323). TRIP is modeled after BGP-4 and advertises
after BGP-4 and advertises reachability and attributes of destina- reachability and attributes of destinations. In its current form,
tions. In its current form, several attributes have already been several attributes have already been defined, such as LocalPreference
defined, such as LocalPreference and MultiExitDisc. Upon standardi- and MultiExitDisc. Additional attributes can be registered with
zation of TRIP, additional attributes can be registered with IANA. IANA. Initially, we would recommend two attributes that would relate
Initially, we would recommend two additional attributes that would to emergency related flows. These being:
relate to emergency related flows. These being:
EmergencyMultiExitDisc EmergencyMultiExitDisc
The EmergencyMultiExitDisc attribute is similar to the The EmergencyMultiExitDisc attribute is similar to the
MultiExitDisc in that it is an inter-domain attribute used MultiExitDisc in that it is an inter-domain attribute used
to express a preference of one or more links over others to express a preference of one or more links over others
between domains. Unlike the MultiExitDisc, this attribute between domains. Unlike the MultiExitDisc, this attribute
specifically identifies links that are preferred for emergency specifically identifies links that are preferred for emergency
related calls that span domains. related calls that span domains.
skipping to change at page 13, line 43 skipping to change at page 13, line 43
With respect to application level signaling for IP telephony, we With respect to application level signaling for IP telephony, we
focus our attention to the Session Initiation Protocol (SIP). focus our attention to the Session Initiation Protocol (SIP).
Currently, SIP has an existing "priority" field in the Request- Currently, SIP has an existing "priority" field in the Request-
Header-Field that distinguishes different types of sessions. The Header-Field that distinguishes different types of sessions. The
five currently defined values are: "emergency", "urgent", "normal", five currently defined values are: "emergency", "urgent", "normal",
"non-urgent", "other-priority". These values are meant to convey "non-urgent", "other-priority". These values are meant to convey
importance to the end-user and have no additional sematics associated importance to the end-user and have no additional sematics associated
with them. with them.
[15] is a work in progress that defines a new header field for SIP [15] is a work in progress example that defines a new header field
known as the Resource Priority Header. This new header field is for SIP known as the Resource Priority Header. This new header field
meant to provide an additional measure of distinction that can influ- is meant to provide an additional measure of distinction that can
ence the behavior of gateways and SIP proxies. The structure of the influence the behavior of gateways and SIP proxies. The structure of
field is in the form of a NameSpace.Priority. The "NameSpace" pro- the field is in the form of a NameSpace.Priority. The "NameSpace"
vides a reference point by which the "Priority" values correspond to. provides a reference point by which the "Priority" values correspond
In the example of the Defence Switched Network (DSN) namespace, six to.
ordered priority values correlating to Multi-Level Priority & Prefer-
ence (MLPP) [21] are defined. Each of the defined values for the DSN
NameSpace have a specific relation or priority to each other. How-
ever, the specific actions enacted on the value, and their relation-
ship to other NameSpaces are subject to policies and SLAs. We expand
on the subject of policies below in section 4.2.
Additional namespaces and value(s) would be registered with IANA. It Additional namespaces and value(s) would be registered with IANA. It
would be our intention to follow the approach taken in [15] and would be our intention to follow the approach taken in [15] and
register a new namespace attributed to IEPS. Unlike [15], we would define a label for a new optional field in SIP to distinguish IEPS
calls from other calls. Assuming [15] becomes the accepted practice,
we would also register a new namespace attributed to IEPS. We would
define a single value (e.g., "authorized-emergency") that would define a single value (e.g., "authorized-emergency") that would
correspond to the NS/EP code point of SS7. This will help facilitate correspond to the single NS/EP code point of SS7. This will help
a seamless interaction between the PSTN and the an IP network acting facilitate a seamless interaction between the PSTN and an IP network
as either an internal backbone or as a peering ISP. acting as either an internal backbone or as a peering ISP.
Note #1: The work put forth by Polk in [34], which describes an This document does not specify the exact actions taken by a SIP node
architecture for MLPP, is similar to the subject of IEPS in the sense upon receipt of the label corresponding to IEPS (authorized-
that both aim at distinguishing certain VoIP flows from others. How- emergency) calls. This is a function of policy and to be articulated
ever, MLPP and IEPS are not the same efforts. One critical differ- in a separate document. We can speculate that in following the
ence is that MLPP involves the use of preemption, while the default objective of increased probability of call completion, there will be
model for IEPS is simply an increase in the probability of call com- a separate queue for IEPS-labeled calls. If a threshold for number
pletion. of calls exists within the SIP server one action may simply be "hold-
ing" the IEPS labeled request for an additional period in case a new
call can be placed. However, we stress this is only an example to
consider.
Note #1: Previous work that has been put forth by Polk in [34], which
describes an architecture for MLPP over IP networks, is similar to
the subject of IEPS in the sense that both aim at distinguishing cer-
tain VoIP flows from others. However, MLPP and IEPS are not the same
efforts. One critical difference is that MLPP involves the use of
preemption, while the default model for IEPS is simply an increase in
the probability of call completion.
Note #2: The term "Priority" has been a subject of strong debate. In Note #2: The term "Priority" has been a subject of strong debate. In
this document, we reference the term based on the terminology inher- this document, we reference the term based on the terminology inher-
ited from other drafts and documents, such as can be found in [15], ited from other drafts and documents, such as can be found in [15],
and the Megaco RFC [23]. However, our focus is aimed at using the and the Megaco RFC [23]. However, our focus is aimed at using the
"priority" value as simply a label by which we distinguish one set of "priority" value as simply a label by which we distinguish one set of
flows from another. flows from another.
4.1.2. Diff-Serv 4.1.2. Diff-Serv
skipping to change at page 17, line 20 skipping to change at page 17, line 25
Discussions have been held in the Audio/Visual Transport (AVT) work- Discussions have been held in the Audio/Visual Transport (AVT) work-
ing group of augmenting RTP so that it can carry a marking that dis- ing group of augmenting RTP so that it can carry a marking that dis-
tinguishes emergency-related traffic from that which is not. Specif- tinguishes emergency-related traffic from that which is not. Specif-
ically, one would define a new extention that contains a "classifier" ically, one would define a new extention that contains a "classifier"
field indicating the condition associated with the packet (e.g., field indicating the condition associated with the packet (e.g.,
authorized-emergency, emergency, normal) [29]. The rationale behind authorized-emergency, emergency, normal) [29]. The rationale behind
this idea was that focusing on RTP would allow one to rely on a point 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. of aggregation that would apply to all payloads that it encapsulates.
However, the AVT group has expressed a rough consensus that placing However, the AVT group has expressed a rough consensus that placing
additional classifier state in the RTP header to denote the impor- additional classifier state in the RTP header to denote the impor-
tance of one flow over another is not an approach that wish to tance of one flow over another is not an approach that they wish to
advance. Objections ranging from relying on SIP to convey importance advance. Objections ranging from relying on SIP to convey importance
of a flow, as well as the possibility of adversely affecting header of a flow, as well as the possibility of adversely affecting header
compression, were expressed. There was also the general feeling that compression, were expressed. There was also the general feeling that
the extension header for RTP should not be used for RTP packet of a the extension header for RTP should not be used for RTP packet of a
flow. flow.
Author's note: There was some debate as to whether to keep the above Author's note: There was some debate as to whether to keep the above
subsection concerning RTP in this document. We have decided to subsection concerning RTP in this document. We have decided to
retain it because it is felt that information concerning directions retain it because it is felt that information concerning directions
that should NOT be taken to support IEPS is important to the commun- that should NOT be taken to support IEPS is important to the commun-
skipping to change at page 18, line 48 skipping to change at page 19, line 6
IEPS type traffic. IEPS type traffic.
4.3. Traffic Engineering 4.3. Traffic Engineering
In those cases where a network operates under the constraints of In those cases where a network operates under the constraints of
SLAs, one or more of which pertains to IEPS based traffic, it can be SLAs, one or more of which pertains to IEPS based traffic, it can be
expected that some form of traffic engineering is applied to the expected that some form of traffic engineering is applied to the
operation of the network. We make no requirements as to which type operation of the network. We make no requirements as to which type
of traffic engineering mechanism is used, but that such a system of traffic engineering mechanism is used, but that such a system
exists and can distinguish and support IEPS signaling and data exists and can distinguish and support IEPS signaling and data
traffic. traffic. We recommend a review by clients and providers of IEPS ser-
vice of [36], which gives an overview and a set of principles of
Internet traffic engineering.
MPLS is generally the first protocol that comes to mind when the sub- MPLS is generally the first protocol that comes to mind when the sub-
ject of traffic engineering is brought up. This notion is hightened ject of traffic engineering is brought up. This notion is hightened
concerning the subject of IP telephony because of MPLS's ability to concerning the subject of IP telephony because of MPLS's ability to
to permit a quasi circuit switching capability to be superimposed on to permit a quasi circuit switching capability to be superimposed on
the current Internet routing model [33]. the current Internet routing model [33].
However, having cited MPLS, we need to stress that it is an intra- However, having cited MPLS, we need to stress that it is an intra-
domain protocol, and so may or may not exist within a given ISP. domain protocol, and so may or may not exist within a given ISP.
Other forms of traffic engineering, such as weighted OSPF, may be the Other forms of traffic engineering, such as weighted OSPF, may be the
skipping to change at page 19, line 45 skipping to change at page 19, line 50
signal the call's higher priority. A secure link between the gateways signal the call's higher priority. A secure link between the gateways
may be set up using IPSec or SIP security functionality. If the end- may be set up using IPSec or SIP security functionality. If the end-
point is an IP device on the carrier's network, the link may be set point is an IP device on the carrier's network, the link may be set
up securely from the ingress gateway to the end device. up securely from the ingress gateway to the end device.
As flows traverse more than one IP network, domains whose peering As flows traverse more than one IP network, domains whose peering
agreements include IEPS support must have means to securely signal a agreements include IEPS support must have means to securely signal a
given flow's IEPS status. They may choose to use physical link secu- given flow's IEPS status. They may choose to use physical link secu-
rity and/or IPSec authentication, combined with traffic conditioning rity and/or IPSec authentication, combined with traffic conditioning
measures to limit the amount of IEPS traffic that may pass between measures to limit the amount of IEPS traffic that may pass between
the two domains. The inter-domain agreement may require the originat- the two domains. The inter-domain agreement may require the
ing network to take responsibility for ensuring only authorized originating network to take responsibility for ensuring only author-
traffic is marked with IEPS priority; the downstream domain may still ized traffic is marked with IEPS priority; the downstream domain may
perform redundant conditioning to prevent the propagation of theft still perform redundant conditioning to prevent the propagation of
and denial of service attacks. Security may be provided between theft and denial of service attacks. Security may be provided
ingress and egress gateways or IP endpoints using IPSec or SIP secu- between ingress and egress gateways or IP endpoints using IPSec or
rity functions. SIP security functions.
When a call originates from an IP device, the ingress network may When a call originates from an IP device, the ingress network may
authorize IEPS traffic over that link as part of its user authentica- authorize IEPS traffic over that link as part of its user authentica-
tion procedures without necessarily communicating with a central IEPS tion procedures without necessarily communicating with a central IEPS
authentication center as happens with POTS-originated calls. These authentication center as happens with POTS-originated calls. These
authentication procedures may occur at the link or network layers, authentication procedures may occur at the link or network layers,
but are entirely at the discretion of the ingress network. That net- but are entirely at the discretion of the ingress network. That net-
work must decide how often it should update its list of authorized work must decide how often it should update its list of authorized
IEPS users based on the bounds it is prepared to accept on traffic IEPS users based on the bounds it is prepared to accept on traffic
from recently-revoked users. from recently-revoked users.
skipping to change at page 22, line 24 skipping to change at page 22, line 30
Figure 2 Figure 2
Given multiple IP domains, and the presumption that SLAs relating to Given multiple IP domains, and the presumption that SLAs relating to
IEPS traffic may exist between them, the need for something like IEPS traffic may exist between them, the need for something like
diff-serv grows with respect to being able to distinguish the emer- diff-serv grows with respect to being able to distinguish the emer-
gency related traffic from other types of traffic. In addition, IP gency related traffic from other types of traffic. In addition, IP
security becomes more important between domains in order to ensure security becomes more important between domains in order to ensure
that the act of distinguishing IEPS-type traffic is indeed valid for that the act of distinguishing IEPS-type traffic is indeed valid for
the given source. the given source.
We conclude this section by mentioning a complimentary work in pro-
gress in providing ISUP transparency across SS7-SIP interworking
[37]. The objective of this effort is to access services in the SIP
network and yet maintain transparency of end-to-end PSTN services.
Not all services are mapped (as per the design goals of [37], so we
anticipate the need for an additional document to specify the mapping
between new SIP labels and existing PSTN code points like NS/EP and
MLPP.
6. Security Considerations 6. Security Considerations
Information on this topic is presented in sections 2 and 4. Information on this topic is presented in sections 2 and 4.
7. References 7. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Braden, R., et. al., "Integrated Services in the Internet 2 Braden, R., et. al., "Integrated Services in the Internet
skipping to change at page 22, line 46 skipping to change at page 23, line 23
3 Braden, R., et. al., "Resource Reservation Protocol (RSVP) 3 Braden, R., et. al., "Resource Reservation Protocol (RSVP)
Version 1, Functional Specification", Proposed Standard, RFC Version 1, Functional Specification", Proposed Standard, RFC
2205, Sept. 1997. 2205, Sept. 1997.
4 Shenker, S., et. al., "Specification of Guaranteed Quality of 4 Shenker, S., et. al., "Specification of Guaranteed Quality of
Service", Proposed Standard, RFC 2212, Sept 1997. Service", Proposed Standard, RFC 2212, Sept 1997.
5 Wroclawski, J., "Specification for Controlled-Load Network 5 Wroclawski, J., "Specification for Controlled-Load Network
Service Element", Proposed Standard, RFC 2211, Sept 1997. Service Element", Proposed Standard, RFC 2211, Sept 1997.
6 Gai, S., et. al., "RSVP Proxy", Internet Draft, Work in 6 Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6
Progress, July 2001. Reservations", Proposed Standard, RFC 3175, September 2001.
7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions", 7 Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions",
Proposed Standard, RFC 2961, April, 2001. Proposed Standard, RFC 2961, April, 2001.
8 Blake, S., et. al., "An Architecture for Differentiated 8 Blake, S., et. al., "An Architecture for Differentiated
Service", Proposed Standard, RFC 2475, Dec. 1998. Service", Proposed Standard, RFC 2475, Dec. 1998.
9 Ash, J., et. al., "Proposed MPLS/DiffServ TE Class Types", Inter- 9 Faucheur, F., et. al., "MPLS Support of Differentiated Services",
net Standards Track, RFC 3270, May 2002.
Draft, Work In Progress, Nov 2001.
10 Farrel, A., et. al., "Fault Tolerance for LDP and CR-LDP", 10 Farrel, A., et. al., "Fault Tolerance for LDP and CR-LDP",
Internet Draft, Work In Progress, October 2001. Internet Draft, Work In Progress, October 2001.
11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821, 11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821,
August 1982. August 1982.
12 Handley, M., et. al., "SIP: Session Initiation Protocol", 12 Handley, M., et. al., "SIP: Session Initiation Protocol",
Proposed Standard, RFC 2543, March 1999. Proposed Standard, RFC 2543, March 1999.
13 ANSI, "Signaling System No. 7(SS7) _ High Probability of 13 ANSI, "Signaling System No. 7(SS7) _ High Probability of
Completion (HPC) Network Capability_, ANSI T1.631, 1993. Completion (HPC) Network Capability_, ANSI T1.631, 1993.
14 Reliable Audio Tool (RAT): 14 Robust Audio Tool (RAT):
http://www-mice.cs.ucl.ac.uk/multimedia/software/rat http://www-mice.cs.ucl.ac.uk/multimedia/software/rat
15 Polk, J., Schulzrinne, H, "SIP Communications Resource Priority 15 Polk, J., Schulzrinne, H, "SIP Communications Resource Priority
Header", Internet Draft, Work In Progress, December, 2001. Header", Internet Draft, Work In Progress, December, 2001.
16 Nichols, K., et. al.,"Definition of the Differentiated Services 16 Nichols, K., et. al.,"Definition of the Differentiated Services
Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed
Standard, RFC 2474, December 1998. Standard, RFC 2474, December 1998.
17 Durham, D., "The COPS (Common Open Policy Service) Protocol", 17 Durham, D., "The COPS (Common Open Policy Service) Protocol",
skipping to change at page 24, line 5 skipping to change at page 24, line 24
19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing 19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing
Over IP", Informational, RFC 2871, June 2000 Over IP", Informational, RFC 2871, June 2000
20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed 20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed
Standard, RFC 2597, June 1999 Standard, RFC 2597, June 1999
21 ITU, "Multi-Level Precedence and Preemption Service, ITU, 21 ITU, "Multi-Level Precedence and Preemption Service, ITU,
Recomendation, I.255.3, July, 1990. Recomendation, I.255.3, July, 1990.
22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", Internet 22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)",
Draft, Work In Progress, April 2001. Standards Track, RFC 3219, January 2002.
23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards 23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards
Track, RFC 3015, November 2000 Track, RFC 3015, November 2000
24 Perkins, C., et al., "RTP Payload for Redundant Audio Data", 24 Perkins, C., et al., "RTP Payload for Redundant Audio Data",
Standards Track, RFC 2198, September, 1997 Standards Track, RFC 2198, September, 1997
25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for 25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for
Generic Forward Error Correction", Standards Track, RFC 2733, Generic Forward Error Correction", Standards Track, RFC 2733,
December, 1999. December, 1999.
26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000, 26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000,
2000. 2000.
27 Brown, I., "Securing IEPS over IP", White Paper, 27 Brown, I., "Securing IEPS over IP", White Paper,
http://iepscheme.net/docs/secure_IEPS.doc http://iepscheme.net/docs/secure_IEPS.doc
28 Folts, H., "Description of an International Emergency Preference 28 "Description of an International Emergency Preference
Scheme (IEPS) ITU-T Recommendation E.106 (Formerly CCITT Scheme (IEPS)", ITU-T Recommendation E.106 March, 2002
Recomendation), Internet Draft, Work In Progress, February 2001
29 Carlberg, K., "The Classifier Extension Header for RTP", Internet 29 Carlberg, K., "The Classifier Extension Header for RTP", Internet
Draft, Work In Progress, October 2001. Draft, Work In Progress, October 2001.
30 National Communications System: http://www.ncs.gov 30 National Communications System: http://www.ncs.gov
31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP", 31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP",
http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/, http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/,
IETF Presentation: IPPM-Voiceip, Aug, 1997 IETF Presentation: IPPM-Voiceip, Aug, 1997
skipping to change at page 25, line 5 skipping to change at page 25, line 19
33 Awduche, D, et al, "Requirements for Traffic Engineering Over 33 Awduche, D, et al, "Requirements for Traffic Engineering Over
MPLS", Informational, RFC 2702, September, 1999. MPLS", Informational, RFC 2702, September, 1999.
34 Polk, J., "An Architecture for Multi-Level Precedence and 34 Polk, J., "An Architecture for Multi-Level Precedence and
Preemption over IP", Internet Draft, Work In Progress, Preemption over IP", Internet Draft, Work In Progress,
November, 2001. November, 2001.
35 "Service Class Designations for H.323 Calls", ITU Draft 35 "Service Class Designations for H.323 Calls", ITU Draft
Recommendation H.GEF.4, September, 2001 Recommendation H.GEF.4, September, 2001
36 Awduche, D., et. al., "Overview and Principles of Internet Traffic
Engineering", Informational, RFC 3272, May 2002.
37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and
Architectures", work in progress, Internet-Draft, June, 2002.
8. Appendix A: Government Telephone Preference Scheme (GTPS) 8. Appendix A: Government Telephone Preference Scheme (GTPS)
This framework document uses U.S. GETS as a target model for defining This framework document uses the T1.631 and ITU IEPS standard as a
a framework for supporting authorized emergency related communication target model for defining a framework for supporting authorized emer-
within the context of IP telephony. We take this position because of gency related communication within the context of IP telephony. We
the various areas that must be considered; from the application layer also use GETS as a helpful model to draw experience from. We take
to the (inter)network layer, in addition to policy, security (author- this position because of the various areas that must be considered;
ized access), and traffic engineering. from the application layer to the (inter)network layer, in addition
to policy, security (authorized access), and traffic engineering.
The U.K. has a different type of authorized use of telephony services The U.K. has a different type of authorized use of telephony services
referred to as the Government Telephone Preference Scheme (GTPS). referred to as the Government Telephone Preference Scheme (GTPS).
This service was introduced in the 1950's at a time when loss of This service was introduced in the 1950's at a time when loss of
power to the PSTN due to war or natural disaster was of prime con- power to the PSTN due to war or natural disaster was of prime con-
cern. If a loss of power did occur, it was felt that the critical cern. If a loss of power did occur, it was felt that the critical
issue was to take action to limit phone usage by the general public issue was to take action to limit phone usage by the general public
so that power would be conserved for use by critical personnel so that power would be conserved for use by critical personnel
involved in an emergency. involved in an emergency.
The design and implementation of GTPS focused on the ability of the The design and implementation of GTPS focused on the ability of the
U.K. PSTN to withdraw outgoing telephone service from the majority U.K. PSTN to withdraw outgoing telephone service from the majority
of the general public. Inbound calls can still be received, but the of the general public. Inbound calls can still be received, but the
net effect of the action is that power for the phone line service is net effect of the action is that power for the phone line service is
conserved. It can probably be argued that power loss is not as conserved. While power loss is still fo concern, a more important
important an issue today as it was back in the 50's. And in fact issue to the U.K. government is is the volume of switched traffic
Oftel, the U.K. regulatory authority, is planning an evolutionary during emergencies. And in fact the Cabinet Office is investigating
change to GTPS so that it reflects current needs and requirements for an evolutionary change to GTPS so that it reflects current needs and
supporting emergency communications through the U.K. PSTN -- such as requirements for supporting emergency communications through the U.K.
congestion, and the ability to provide roaming authorized access like PSTN -- such as congestion, and the ability to provide roaming
that of GETS. authorized access like that of GETS.
At present, all local exchange access points (ie, phones) are divided
into three categories:
1: Time of War: people that are involved in operations and planning At present, GTPS only applies to local loop lines of BT, Kingston,
of a war or war conditions and Cable & Wireless within the UK. The lines are divided into
2: Natural Disaster: individuals that are involved in recovery and Categories 1, 2, and 3. The first two categories involve authorized
operations associated with natural disasters. personnel that are involved in emergencies such as natural disasters.
3: General Public: people that are not associated with categories Catergory 3 identifes the general public.
1 and 2, which is essentially over 99% of the population.
Unlike the roaming ability of GETS users, GTPS associates preference Unlike the roaming ability of GETS users, GTPS associates preference
with an originating phone. This simplifies the process of determin- with an originating line. This simplifies the process of determining
ing who is allowed outbound phone service, but it is also quite res- who is allowed outbound phone service, but it is also quite restric-
trictive in its usage. Hence, individuals that want preferential tive in its usage. Hence, individuals that need preferential service
service must use the phone that has been designated as Category 1 or must use the phone that has been designated as Category 1 or 2.
2. Note: for the general public, pay phones have been designated as Note: for the general public, pay phones have been designated as
Category 2 so that 999 (emergency calls to fire or police) can be Category 2 so that 999 (calls the emergency services operator) can be
made. made.
In 1984, an updated version of GTPS was made available following the An updated version of GTPS has been made available following the
deregulation of the U.K. phone system. In this new scheme, local deregulation of the U.K. phone system. In this new scheme, local
exchanges retained the three category system while inter-exchange exchanges retained the three category system while inter-exchange
calls use call-gaping. Priority marks, via C7/NUP, would bypass the calls use call-gaping. Priority marks, via C7/NUP, would bypass the
call-gaping. The authority to activate GTPS was also extended to the call-gaping. Exchanges belonging to other licensed operators (i.e.,
46 Constables (i.e., local police chiefs) of the U.K. -- each being not BT, Kingston, or C&W) are not so equiped and will only tran-
responsible for their own jurisdiction. sparently pass on "priority" marks, without affecting their own use
of call-gapping. The authority to activate GTPS has been extended to
either a central or delegated authority.
8.1. GTPS and the Framework Document 8.1. GTPS and the Framework Document
The design of the current GTPS, with its designation of preference The design of the current GTPS, with its designation of preference
based on physical static devices, precludes the need for several based on physical static devices, precludes the need for several
aspects presented in this document. However, one component that can aspects presented in this document. However, one component that can
have a direct correlation is the labeling capability of the proposed have a direct correlation is the labeling capability of the proposed
Resource Priority extension to SIP. In the case of GTPS, one simply Resource Priority extension to SIP. In the case of GTPS, one simply
needs to define a new NameSpace that will define values for each of needs to define a new NameSpace that will define values for each of
its three Categories of users. These new labels will then allow a its three Categories of users. These new labels will then allow a
more transparant interoperation between IP telephony using SIP and more transparant interoperation between IP telephony using SIP and
the U.K. PSTN that supports GTPS. the U.K. PSTN that supports GTPS. However, a strong possibility
exists that the IETF will discourage the registration of NameSpaces
attributed to specific organizations or geo-political boundaries. In
this case, the private definition of a NameSpace (one that is not
registered with IANA) may need to be used by systems like GTPS.
Restricting outbound call establishment within the context of IP Restricting outbound call establishment within the context of IP
telephony and SIP servers is a policy issue. Service Level Agree- telephony and SIP servers is a policy issue. Service Level Agree-
ments, presumably under the guidance or direction of local laws and ments, presumably under the guidance or direction of local laws and
regulations would determine the characteristics of the policy. regulations would determine the characteristics of the policy.
9. Appendix B: Related Standards Work 9. Appendix B: Related Standards Work
The process of defining various labels to distinguish calls has been, The process of defining various labels to distinguish calls has been,
and continues to be, pursued in other standards groups. As mentioned and continues to be, pursued in other standards groups. As mentioned
skipping to change at page 28, line 5 skipping to change at page 28, line 27
priorityExtension INTEGER (0..255) OPTIONAL; priorityExtension INTEGER (0..255) OPTIONAL;
requiredClass NULL OPTIONAL requiredClass NULL OPTIONAL
tokens SEQUENCE OF ClearToken OPTIONAL tokens SEQUENCE OF ClearToken OPTIONAL
cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL
} }
The advantage in using the GenericData parameter is that an existing The advantage in using the GenericData parameter is that an existing
parameter is used, as opposed to defining a new parameter and causing parameter is used, as opposed to defining a new parameter and causing
subsequent changes in existing H.323/H.225 documents. subsequent changes in existing H.323/H.225 documents.
9.2. Study Group 11 (ITU)
To Be Done...
9.3. T1S1 (ANSI)
To Be Done...
10. Acknowledgments 10. Acknowledgments
The authors would like to acknowledge the helpful comments, opinions, The authors would like to acknowledge the helpful comments, opinions,
and clarifications of Stu Goldman, James Polk, Dennis Berg, as well and clarifications of Stu Goldman, James Polk, Dennis Berg, as well
as those comments received from the IEPS and IEPREP mailing lists. as those comments received from the IEPS and IEPREP mailing lists.
Additional thanks to Peter Walker of Oftel for private discussions on Additional thanks to Peter Walker of Oftel for private discussions on
the operation of GTPS, and Gary Thom on clarifications of the SG16 the operation of GTPS, and Gary Thom on clarifications of the SG16
draft contribution. draft contribution.
11. Author's Addresses 11. Author's Addresses
skipping to change at page 29, line 26 skipping to change at page 29, line 26
4.1 Signaling & State Information ................................ 13 4.1 Signaling & State Information ................................ 13
4.1.1 SIP ........................................................ 13 4.1.1 SIP ........................................................ 13
4.1.2 Diff-Serv .................................................. 14 4.1.2 Diff-Serv .................................................. 14
4.1.3 RTP ........................................................ 16 4.1.3 RTP ........................................................ 16
4.1.4 MEGACO/H.248 ............................................... 17 4.1.4 MEGACO/H.248 ............................................... 17
4.2 Policy ....................................................... 18 4.2 Policy ....................................................... 18
4.3 Traffic Engineering .......................................... 18 4.3 Traffic Engineering .......................................... 18
4.4 Security ..................................................... 19 4.4 Security ..................................................... 19
5. Key Scenarios ................................................. 20 5. Key Scenarios ................................................. 20
6. Security Considerations ....................................... 22 6. Security Considerations ....................................... 22
7. References .................................................... 22 7. References .................................................... 23
8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 25 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 25
8.1 GTPS and the Framework Document .............................. 26 8.1 GTPS and the Framework Document .............................. 26
9. Appendix B: Related Standards Work ............................ 26 9. Appendix B: Related Standards Work ............................ 27
9.1 Study Group 16 (ITU) ......................................... 27 9.1 Study Group 16 (ITU) ......................................... 27
9.2 Study Group 11 (ITU) ......................................... 28
9.3 T1S1 (ANSI) .................................................. 28
10. Acknowledgments .............................................. 28 10. Acknowledgments .............................................. 28
11. Author's Addresses ........................................... 28 11. Author's Addresses ........................................... 28
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of
ing Internet standards in which case the procedures for copyrights developing Internet standards in which case the procedures for copy-
defined in the Internet Standards process must be followed, or as rights defined in the Internet Standards process must be followed, or
required to translate it into languages other than English. as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided as an This document and the information contained herein is provided as an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE. CHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/