2. Future Emergency Telecommunication Scenarios over the Internet Dr. Ken Carlberg k.carlberg@cs.ucl.ac.uk Emergency Telecommunications Workshop 26’th-27’th, February 2002, ETSI, Sophia Antipolis, France

3. Outline  Background  The Challenge:  Emergency Services over the Internet  Services & Protocols  Operational Scenarios  Usage Scenarios  Summary

4. 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)

5. 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

6. 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

7. 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

8. 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

9. VoIP with QoS: Near Term  IP Backbone  IP as a private network  Single control of resources  Single-Hop ISPs  No Inter-ISP SLAs  Single control of resources SS7 Signaling Evolution towards NGN VoIP (SIP/H.323 over IP) SS7 Client IP Stub ISPCloud PSTN ISPCloud WFQ Diff-Serv (AF) Client IP Stub Telcos Stub IP Domain PSTN Internet VoIP PBX

10. 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

11. 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 TRIP Route  Application Layer routing  e.g., Telephony Routing over IP (TRIP)

12. ETS Operation: Mid Term (2)  Admission Control  Performed at edge of diff- serv domain  Core/Internal congestion  AF: use drop precedence  EF: requires careful traffic engineering to avoid congestion Admission Control Call/Data (1) (emergency) Call/Data (2) Admission Control Call/Data (1) (emergency) Call/Data (2)  Potential augmentation  New code point to distinguish emergency EF from normal EF

13. 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”

14. 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

15. 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