IP Interconnect

1. IP Interconnect Ian Jenkins Chief Voice Technologist, Group CTO

2. NICC (Network Interoperability Consultative Committee) • UK Telecommunications Industry Group • Established early 1990’s following Duopoly Review to advise Oftel/Ofcom on Interconnect and Interoperability Issues • Produces UK technical specifications based on international standards • Been re-organised to focus on NGN standards • Open to all UK Telecoms Industry (network operators, service provided, equipment manufacturers & suppliers • Agreements reached by consensus.

3. NICC Organisation NICC • Independent chair,Ofcom secretary • Sets direction, policy & priorities TSG • Manages technical work • Chair: Simon Sporton*, Vodafone • Secretary: Nick Ireland+, BT NICC Technical Steering Group (TSG) Technical and Project Groups * simon.sporton@vf.vodafone.co.uk + nick.ireland@bt.com

4. NICC NGN Study Areas End-to-end QoS Group • Spec on E2E QoS for voice services produced and awaiting NICC decision (expected 27 January 2005) DSL Group • Revising ANFP for inclusion of ADSL2+ and VDSL2. IP Interconnect • IP Interconnect

5. NICC NGN IP Interconnect • Priority given to support of PSTN/ISDN services; • No study on data services to date. • 5 working groups agreed • Architecture • Signalling • Transport • Security • Management

6. NICC NGN IP Interconnect (contd) Architecture Group • Initial meetings; management & security issues identified • BT will submit proposal for IP Interconnect architecture to next meeting in February 2005 Signalling Group • IP interconnect - SIP-I agreed with I = UK ISUP • Work on UK specific requirements (eg 999/112, CLI, Clear 64Kbps) required. • Signalling transport protocol (UDP or SCTP) to be decided Transport Group • Initial discussions held; • Input required on network operator’s requirements

7. Dependencies ETSI SIP-I endorsement January/February 2005 End of March for NICC is timeframe required for definition to vendors to enable timely procurement of solutions. Needs industry commitment to resource working groups. Industry engagement with NICC Technical Groups - contact nick.ireland@bt.com

8. IP Interconnect Architecture …. …..BT Contribution Preview • Functional Model • Independent of Physical Realisation • Multi-service capable • PSTN/ISDN initial focus

9. Transport PSTN -> SIP-I MM -> SIP Control Plane Bearer Plane Management Plane Control Plane IP N/W(s) IP N/W(s) Multi-Service IP Interconnect Functional Model • Transport:- • Logically Pt-Pt Virtual Pipes • IP Adrs space / VP • Bandwidth allocation / VP • Call Control • Session negotiation (inc bandwidth) • Session connexion • Session policing • Session Usage Recording NGN A NGN B Management Flows Mangmt Mangmt • Signalling BGW:- • Firewall • Authentication • Privacy Edge Session Cntr Edge Session Cntr B/W Mangt B/W Mangt • Session BGW:- • Firewall Pinhole Control • NAT • Packet Market Policing Signalling Border G/W Signalling Border G/W • Bandwidth management of media stream virtual pipe Signalling Streams Session Border G/W Session Border G/W • Data BGW:- • To defined for each service QoS Media Streams Data Border G/W Data Border G/W Other Service Streams

10. Transport PSTN -> SIP-I MM -> SIP Management Plane Control Plane Control Plane Bearer Plane IP N/W(s) IP N/W(s) Multi-Service IP Interconnect Functional Model NGN A NGN B Management Flows Mangmt Mangmt Edge Session Cntr Edge Session Cntr B/W Mangt B/W Mangt Signalling Border G/W Signalling Border G/W Signalling Streams Session Border G/W Session Border G/W QoS Media Streams Data Border G/W Data Border G/W Other Service Streams

11. Multi-service NNI Transport Requirements Termination of NNI trail. (Used for monitoring) NNI Physical connection Adaptation of service signal to NNI signal NNI signal mux/switch Service 1 Service 1 Service 2 Service 2 Service N Service N • Supports: • 1. Multiple NNI trails. • 2. Secure separation of trails by labels transparent to service. • 3. Guarantees bandwidth and QoS for service. • 4. Labels statically configured. • (Dynamic signalling later?) • 5. NNI trails NOT resilient! Supports: 1. Multiple NNI physical connections. 2. Resilient physical connections Example of this function is a border gateway Loosely using terminology & symbols from G.805/9.

12. Multi-service NNI Transport Examples Ethernet VLAN per service. Manual planning of bandwidth per VLAN. Policing/Scheduling of bandwidth per VLAN. Fast spanning tree. NNI Border G/W PSTNoIP Media PSTNoIP Media PSTNoIP Sig. PSTNoIP Sig. Sig. F/W Service N Service N • Supports: • 1. Multiple NNI trails. • 2. Secure separation of trails by labels transparent to service. • 3. Guarantees bandwidth and QoS for service. • 4. Labels statically configured. • (Dynamic signalling later?) • 5. NNI trails NOT resilient! Breaks if Service N = Ethernet already using QinQ! Use MAC in MAC instead? Breaks if Service N = SDH VCs!

13. Multi-service NNI Transport Examples SDH VC per service. Use GFP to transport Ethernet clients. SDH 1+1 protection. NNI Border G/W PSTNoIP Media PSTNoIP Media PSTNoIP Sig. PSTNoIP Sig. Sig. F/W Service N Service N • ISSUES: • Interworking GFP from different vendors? • Cost of GFP capable SDH kit? • UBR/VBR/AF type QoS not supported efficiently – may waste bandwidth on NNI. May only be an issue if: • NNI is long distance. • A majority of services bandwidth is heavily contended UBR/VBR/AF. • Supports: • 1. Multiple NNI trails. • 2. Secure separation of trails by labels transparent to service. • 3. Guarantees bandwidth and QoS for service. • 4. Labels statically configured. • (Dynamic signalling later?) • 5. NNI trails NOT resilient!