Download PowerPoint - EMTEL

Future Emergency
Telecommunication Scenarios
over the Internet
Emergency Telecommunications Workshop
26’th-27’th, February 2002, ETSI,
Sophia Antipolis, France
Dr. Ken Carlberg
[email protected]
Outline
Background
The Challenge:
Emergency Services over the Internet
Services & Protocols
Operational Scenarios
Usage Scenarios
Summary
Background: Internet
A network of networks
Self autonomy
Minimal requirements to be an ISP
May use routing protocols
May use non-FIFO queues
No traffic engineering requirements
Most congestion occurs at access points
Tier-1 ISPs usually have high excess capacity at
exchange points
U.S. centric view at times
Counter example includes Trans-Atlantic link(s)
Background: Internet (2)
Default service model is Best Effort
“send and pray”
No minimal level of QoS
TCP is ~90-95% of traffic load
Adaptive to congestion, but cost is degraded service
Security is an issue with IP networks
Denial of service: NIMDA, ICMP Echo Request, …
Spoofing
Challenge
Distinguish emergency traffic
Provide separate level of service
Policy and/or regulatory issue
Value added services
Alternate path routing
Interoperation with PSTN
Mapping code points (at a minimum)
 Achieving the above with minimal changes to
existing IP protocols
Services & Protocols
Past, Current, and/or On-Going (sample set)
SIP/Megaco/H.323
MPLS
Diff-serv
Int-Serv/RSVP
Instant Messaging & Presence
Other
WFQ
RED
Observations
 Existence of protocols does NOT equate to
availability by vendors or service providers
MPLS
Local domain service
Complex and possibly overkill for many ISPs
Int-Serv/RSVP
Market rejection of end-to-end model
Diff-serv
Local domain service
Basic (AF) service can be accomplished with WFQ/RED
So,….be a pessimist about what exists, and leverage
what you can use
VoIP with QoS: Near Term
 IP Backbone
 Single-Hop ISPs
 IP as a private network
 Single control of resources
Telcos
 No Inter-ISP SLAs
 Single control of resources
SS7
Evolution
towards NGN
SS7
Signaling
VoIP
(SIP/H.323 over IP)
WFQ
ISP
Cloud
Internet
PSTN
Stub IP Domain
VoIP
PSTN
PBX
Client
IP Stub
ISP
Cloud
Diff-Serv (AF)
Client
IP Stub
ETS Operation: Near Term
Label calls for ETS
SIP Resource Field (draft)
H.323 Priority Field (draft)
 Policy defines actions (part of SLA)
Preemption / non-preemption
Traffic engineered paths
SLA’s dictate usage (e.g., diff-serv code points)
e.g., #1) AF (Class 1) for Signaling, EF for VoIP
e.g., #2) AF (Class 3) for Signaling & VoIP
Access control at the edge
ETS Operation: Mid Term
 Alternate path routing
 BGP could not support
Emergency attribute
Routers straining to
support number of routes
Convergence time
problem
Network
View
SIP
Server
TRIP
View
 Application Layer routing
 e.g., Telephony Routing over
IP (TRIP)
TRIP
Route
ETS Operation: Mid Term (2)
 Admission Control
 Performed at edge of diffserv domain
Admission
Control
 Core/Internal congestion
 AF: use drop precedence
 EF: requires careful traffic
engineering to avoid
congestion
Call/Data (1)
Call/Data (2)
(emergency)
 Potential augmentation
 New code point to
distinguish emergency EF
from normal EF
Admission
Control
Call/Data (1)
(emergency)
Call/Data (2)
ETS Usage
Traveling Authentication & Capability
Similar to GETS
Non-ubiquitous service
ETS “islands” connected via best effort service
Goal is ever increasing wide spread support
Payment and/or regulation are important
issues because….
…..“There is no such thing as a free lunch”
ETS Future?
 QoS Gateways
Forward Error Correction (FEC)
Redundant transmission
Transcoding
 Semi-Active Networking
Very leading edge approach
E.g., Cisco Intelligence Engine 2100
XML/policy based control of network elements
Negotiated service with user
Degraded service if admission control fails
Summary
Autonomous & independent nature of IP
networks makes support of ETS difficult
Be pessimistic about available services
“We” probably have 85% of what is needed
to supporting ETS
More options will exist for the ETS user