draft-ietf-ieprep-framework-08.txt   draft-ietf-ieprep-framework-09.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
February 5, 2004 Ian Brown February 5, 2004 Ian Brown
UCL UCL
Cory Beard Cory Beard
UMKC UMKC
Framework for Supporting ETS in IP Telephony Framework for Supporting ETS in IP Telephony
<draft-ietf-ieprep-framework-08.txt> <draft-ietf-ieprep-framework-09.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 35 skipping to change at page 3, line 32
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.
[11] has defined a priority field for SMTP, but it is only for map- [11] has defined a priority field for SMTP, but it is only for map-
ping with X.400 and is not meant for general usage. SIP [12] has an ping with X.400 and is not meant for general usage. SIP [12] has an
embedded field denoting "priority", but it is only targeted towards embedded field denoting "priority", but it is only targeted towards
the end-user and is not menat not provide indication to the underly- the end-user and is not meant not provide indication to the underly-
ing network or end-to-end applications. ing network or end-to-end applications.
Given the emergence of IP telephony, a natural inclusion of its ser- Given the emergence of IP telephony, a natural inclusion of its ser-
vice is an ability to support existing emergency related services. vice is an ability to support existing emergency related services.
Typically, one associates emergency calls with "911" telephone ser- Typically, one associates emergency calls with "911" telephone ser-
vice in the U.S., or "999" in the U.K. -- both of which are attri- vice in the U.S., or "999" in the U.K. -- both of which are attri-
buted to national boundaries and accessible by the general public. buted to national boundaries and accessible by the general public.
Outside of this exists emergency telephone services that involved Outside of this exists emergency telephone services that involved
authorized usage, as described in the following subsection. authorized usage, as described in the following subsection.
skipping to change at page 4, line 41 skipping to change at page 4, line 38
As in the case of GETS, IEPS promotes mechanisms like extended queu- As in the case of GETS, IEPS promotes mechanisms like extended queu-
ing, alternate routing, and exemption from restrictive management ing, alternate routing, and exemption from restrictive management
controls in order to increase the probability that international controls in order to increase the probability that international
emergency calls will be established. The specifics of how this is to emergency calls will be established. The specifics of how this is to
be accomplished are to be defined in future ITU document(s). be accomplished are to be defined in future ITU document(s).
1.2. Scope of this Document 1.2. Scope of this Document
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 ETS within the context of IP telephony, though not necessarily of ETS within the context of IP telephony versus simply Voice over
Voice over IP. We make a distinction between these two by treating IP. We make a distinction between these two by treating IP telephony
IP telephony as a subset of VoIP, where in the former case we assume as a subset of VoIP, where in the former case we assume some form of
some form of application layer signaling is used to explicitly estab- application layer signaling is used to explicitly establish and main-
lish and maintain voice data traffic. This explicit signaling capa- tain voice data traffic. This explicit signaling capability provides
bility provides the hooks from which VoIP traffic can be bridged to the hooks from which VoIP traffic can be bridged to the PSTN.
the PSTN.
An example of this distinction is when the Robust 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 before devices that use a signaling protocol to establish a call before
sending data towards the destination. 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
skipping to change at page 7, line 12 skipping to change at page 7, line 8
Another aspect to consider is that there are existing architectures Another aspect to consider is that there are existing architectures
and protocols from other standards bodies that support emergency and protocols from other standards bodies that support emergency
related communications. The effort in interoperating with these sys- related communications. The effort in interoperating with these sys-
tems, presumably through gateways or similar type nodes with IETF tems, presumably through gateways or similar type nodes with IETF
protocols, would foster a need to distinguish ETS flows from other protocols, would foster a need to distinguish ETS flows from other
flows. One reason would be the scenario of triggering ETS service flows. One reason would be the scenario of triggering ETS service
from an IP network. from an IP network.
Finally, we take into consideration the requirements of [39, 40] in Finally, we take into consideration the requirements of [39, 40] in
discussing the protocols and mechanisms below in Secytion 4. In discussing the protocols and mechanisms below in Section 4. In doing
doing this, we do not make a one-to-one mapping of protocol discus- this, we do not make a one-to-one mapping of protocol discussion with
sion with requirement. Rather, we make sure the discussion of Sec- requirement. Rather, we make sure the discussion of Section 4 does
tion 4 does not violet any of the requirements in [39,40]. not violet any of the requirements in [39,40].
4. Protocols and Capabilities 4. Protocols and Capabilities
In this section, we take the objectives presented above and present a In this section, we take the objectives presented above and present a
set of protocols and capabilities that can be used to achieve them. set of protocols and capabilities that can be used to achieve them.
Given that the objectives are predominantly atomic in nature, the Given that the objectives are predominantly atomic in nature, the
measures used to address them are to be viewed separately with no measures used to address them are to be viewed separately with no
specific dependency upon each other as a whole. Various protocols specific dependency upon each other as a whole. Various protocols
and capabilities may be complimentary to each other, but there is no and capabilities may be complimentary to each other, but there is no
need for all to exist given different scenarios of operation, and need for all to exist given different scenarios of operation, and
that ETS support is not expected to be a ubiquitously available ser- that ETS support is not expected to be a ubiquitously available ser-
vice. We divide this section into 4 areas: vice. We divide this section into 5 areas:
1) Signaling 1) Signaling
2) Policy 2) Policy
3) Traffic Engineering 3) Traffic Engineering
4) Security 4) Security
5) Routing 5) Routing
4.1. Signaling & State Information 4.1. Signaling & State Information
Signaling is used to convey various information to either intermedi- Signaling is used to convey various information to either intermedi-
skipping to change at page 8, line 51 skipping to change at page 8, line 47
bits without defining their intended meaning (e.g.,the drop pre- bits without defining their intended meaning (e.g.,the drop pre-
cedence approach of Assured Forwarding). The one caveat to this cedence approach of Assured Forwarding). The one caveat to this
statement are the set of DSCP bits set aside for experimental pur- statement are the set of DSCP bits set aside for experimental pur-
poses. But as the name implies, experimental is for internal examina- poses. But as the name implies, experimental is for internal examina-
tion and use and not for standardization. tion and use and not for standardization.
Comments Comments
-------- --------
It is important to note that as of the time that this document was It is important to note that as of the time that this document was
written, the IETF has been taking a conservative approach in written, the IETF has been taking a conservative approach in specify-
specifying new PHBs. This is because the number of code points that ing new PHBs. This is because the number of code points that can be
can be defined is relatively small and understandably considered a defined is relatively small and understandably considered a scarce
scarce resource. Therefore, the possibility of a new PHB being resource. Therefore, the possibility of a new PHB being defined for
defined for emergency related traffic is at best a long term project emergency related traffic is at best a long term project that may or
that may or may not be accepted by the IETF. may not be accepted by the IETF.
In the near term, we would initially suggest using the Assured For- In the near term, we would initially suggest using the Assured For-
warding (AF) PHB [20] for distinguishing emergency traffic from other warding (AF) PHB [20] for distinguishing emergency traffic from other
types of flows. At a minimum, AF could be used for the different SIP types of flows. At a minimum, AF could be used for the different SIP
call signaling messages. If EF was also supported by the domain, call signaling messages. If EF was also supported by the domain,
then it would be used for IP telephony data packets. Otherwise, then it would be used for IP telephony data packets. Otherwise,
another AF class would be used for those data flows. another AF class would be used for those data flows.
4.1.3. Variations Related to Diff-Serv and Queuing 4.1.3. Variations Related to Diff-Serv and Queuing
skipping to change at page 15, line 19 skipping to change at page 15, line 19
4.4.3. Confidentiality and integrity 4.4.3. Confidentiality and integrity
When ETS communications are being used to respond to a deliberate When ETS communications are being used to respond to a deliberate
attack, it is important that they cannot be altered or intercepted to attack, it is important that they cannot be altered or intercepted to
worsen the situation -- for example, by changing the orders to first worsen the situation -- for example, by changing the orders to first
responders such as firefighters or by using knowledge of the emer- responders such as firefighters or by using knowledge of the emer-
gency response to cause further damage. gency response to cause further damage.
The integrity and confidentiality of such communications should The integrity and confidentiality of such communications should
therefore be protected as far as possible using end-to-end security therefore be protected as far as possible using end-to-end security
protocols such as IPSec or the security functionality in SIP and protocols such as IPSec or the security functionality in SIP and SRTP
SRTP. Where communications involve other types of network such as the [43]. Where communications involve other types of network such as the
PSTN, the IP side should be protected and any security functionality PSTN, the IP side should be protected and any security functionality
available in the other network should be used. available in the other network should be used.
4.5. Alternate Path Routing 4.5. Alternate Path Routing
This subject involves the ability to discover and use a different This subject involves the ability to discover and use a different
path to route IP telephony traffic around congestion points and thus path to route IP telephony traffic around congestion points and thus
avoid them. Ideally, the discovery process would be accomplished in avoid them. Ideally, the discovery process would be accomplished in
an expedient manner (possibly even a priori to the need of its an expedient manner (possibly even a priori to the need of its
existence). At this level, we make no assumptions as to how the existence). At this level, we make no assumptions as to how the
skipping to change at page 18, line 50 skipping to change at page 18, line 46
the defined set of Per-Hop Behaviors, is reduced under this scenario. the defined set of Per-Hop Behaviors, is reduced under this scenario.
Another function that has little or no importance within the closed Another function that has little or no importance within the closed
IP environment of Figure 1 is that of IP security. The fact that 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, each administrative domain peers with each other as part of the PSTN,
means that existing security, in the form of Personal Identification means that existing security, in the form of Personal Identification
Number (PIN) authentication (under the context of telephony infras- Number (PIN) authentication (under the context of telephony infras-
tructure protection), is the default scope of security. We do not tructure protection), is the default scope of security. We do not
claim that the reliance on a PIN based security system is highly claim that the reliance on a PIN based security system is highly
secure or even desirable. But, we use this system as a default secure or even desirable. But, we use this system as a default
mechanism in order to avoid placing additional requirements on mechanism in order to avoid placing additional requirements on exist-
existing authorized emergency telephony systems. ing authorized emergency telephony systems.
Multiple IP Administrative Domains Multiple IP Administrative Domains
---------------------------------- ----------------------------------
We view the scenario of multiple IP administrative domains as a We view the scenario of multiple IP administrative domains as a
superset of the previous scenario. Specifically, we retain the superset of the previous scenario. Specifically, we retain the
notion that the IP telephony system peers with the existing PSTN. In notion that the IP telephony system peers with the existing PSTN. In
addition, segments addition, segments
(i.e., portions of the Internet) may exchange signaling with other IP (i.e., portions of the Internet) may exchange signaling with other IP
administrative domains via non-PSTN signaling protocols like SIP. administrative domains via non-PSTN signaling protocols like SIP.
Legacy Next Generation Next Generation Legacy Next Generation Next Generation
Carrier Carrier Carrier Carrier Carrier Carrier
skipping to change at page 19, line 42 skipping to change at page 19, line 37
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 ETS-type traffic is indeed valid for that the act of distinguishing ETS-type traffic is indeed valid for
the given source. the given source.
We conclude this section by mentioning a complimentary work in pro- We conclude this section by mentioning a complimentary work in pro-
gress in providing ISUP transparency across SS7-SIP interworking gress in providing ISUP transparency across SS7-SIP interworking
[37]. The objective of this effort is to access services in the SIP [37]. The objective of this effort is to access services in the SIP
network and yet maintain transparency of end-to-end PSTN services. 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 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 anticipate the need for an additional document to specify the mapping
between new SIP labels and existing PSTN code points like NS/EP and between new SIP labels and existing PSTN code points like NS/EP and
MLPP. 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
skipping to change at page 23, line 5 skipping to change at page 22, line 47
Emergency Telecommunications Service", Informational, RFC 3690 Emergency Telecommunications Service", Informational, RFC 3690
Feb 2004 Feb 2004
41 Meyers, D., "Some Thoughts on CoS and Backbone Networks" 41 Meyers, D., "Some Thoughts on CoS and Backbone Networks"
http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf
IETF Presentation: IEPREP, Dec, 2002 IETF Presentation: IEPREP, Dec, 2002
42 Huston, G., "Commentary on Inter-Domain Routing In the Internet", 42 Huston, G., "Commentary on Inter-Domain Routing In the Internet",
Informational, RFC 3221, December 2001. Informational, RFC 3221, December 2001.
43 Baugher, M, et. al., "The Secure Real-Time Transport Protocol
(SRTP)", Proposed Standard, RFC 3711, March, 2004.
8. Appendix A: Government Telephone Preference Scheme (GTPS) 8. Appendix A: Government Telephone Preference Scheme (GTPS)
This framework document uses the T1.631 and ITU IEPS standard as a This framework document uses the T1.631 and ITU IEPS standard as a
target model for defining a framework for supporting authorized emer- target model for defining a framework for supporting authorized emer-
gency related communication within the context of IP telephony. We gency related communication within the context of IP telephony. We
also use GETS as a helpful model to draw experience from. We take also use GETS as a helpful model to draw experience from. We take
this position because of the various areas that must be considered; this position because of the various areas that must be considered;
from the application layer to the (inter)network layer, in addition from the application layer to the (inter)network layer, in addition
to policy, security (authorized access), and traffic engineering. to policy, security (authorized access), and traffic engineering.
skipping to change at page 26, line 15 skipping to change at page 26, line 15
1. Introduction ................................................... 2 1. Introduction ................................................... 2
1.1 Emergency Related Data ....................................... 3 1.1 Emergency Related Data ....................................... 3
1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3 1.1.1 Government Emergency Telecommunications Service (GETS) ..... 3
1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4 1.1.2 International Emergency Preparedness Scheme (IEPS) ......... 4
1.2 Scope of this Document ....................................... 4 1.2 Scope of this Document ....................................... 4
2. Objective ..................................................... 6 2. Objective ..................................................... 6
3. Considerations ................................................ 6 3. Considerations ................................................ 6
4. Protocols and Capabilities .................................... 7 4. Protocols and Capabilities .................................... 7
4.1 Signaling & State Information ................................ 7 4.1 Signaling & State Information ................................ 7
4.1.1 SIP ........................................................ 8 4.1.1 SIP ........................................................ 7
4.1.2 Diff-Serv .................................................. 8 4.1.2 Diff-Serv .................................................. 8
4.1.3 Variations Related to Diff-Serv and Queuing ................ 9 4.1.3 Variations Related to Diff-Serv and Queuing ................ 9
4.1.4 RTP ........................................................ 10 4.1.4 RTP ........................................................ 9
4.1.5 GCP/H.248 .................................................. 11 4.1.5 GCP/H.248 .................................................. 11
4.2 Policy ....................................................... 11 4.2 Policy ....................................................... 11
4.3 Traffic Engineering .......................................... 12 4.3 Traffic Engineering .......................................... 12
4.4 Security ..................................................... 13 4.4 Security ..................................................... 13
4.4.1 Denial of Service ........................................... 13 4.4.1 Denial of Service ........................................... 13
4.4.2 User authorization .......................................... 14 4.4.2 User authorization .......................................... 14
4.4.3 Confidentiality and integrity ............................... 15 4.4.3 Confidentiality and integrity ............................... 15
4.5 Alternate Path Routing ....................................... 15 4.5 Alternate Path Routing ....................................... 15
4.6 End-to-End Fault Tolerance ................................... 16 4.6 End-to-End Fault Tolerance ................................... 16
5. Key Scenarios ................................................. 17 5. Key Scenarios ................................................. 17
6. Security Considerations ....................................... 20 6. Security Considerations ....................................... 19
7. References .................................................... 20 7. References .................................................... 20
8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23 8. Appendix A: Government Telephone Preference Scheme (GTPS) ..... 23
8.1 GTPS and the Framework Document .............................. 23 8.1 GTPS and the Framework Document .............................. 23
9. Appendix B: Related Standards Work ............................ 23 9. Appendix B: Related Standards Work ............................ 23
9.1 Study Group 16 (ITU) ......................................... 24 9.1 Study Group 16 (ITU) ......................................... 24
10. Acknowledgments .............................................. 25 10. Acknowledgments .............................................. 25
11. Author's Addresses ........................................... 25 11. Author's Addresses ........................................... 25
Full Copyright Statement Full Copyright Statement
 End of changes. 

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