Transcript IP Interconnect

IP Interconnect
Ian Jenkins
Chief Voice Technologist, Group CTO
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.
NICC Organisation
NICC
NICC
• Independent chair,
Ofcom secretary
• Sets direction, policy & priorities
Technical Steering
Group (TSG)
TSG
• Manages technical work
• Chair: Simon Sporton*, Vodafone
• Secretary: Nick Ireland+, BT
Technical and
Project Groups
* [email protected]
+ [email protected]
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
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
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
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 [email protected]
IP Interconnect Architecture ….
…..BT Contribution Preview
• Functional Model
• Independent of Physical Realisation
• Multi-service capable
• PSTN/ISDN initial focus
Multi-Service IP Interconnect Functional Model
NGN A
NGN B
Management Plane
Control Plane
B/W
Mangt
Control Plane
Bearer Plane
Transport
Transport:• Call Control
• Logically Pt-Pt Virtual Pipes
• Session negotiation (inc
• IP Adrs space / VP
Management
bandwidth)
Mangmt
Mangmt
• Bandwidth allocation / VP
• Session connexion Flows
• Session policing
• Session UsageSignalling
RecordingBGW:-
MM -> SIP
• Firewall
• Authentication
• PSTN
Privacy-> SIP-I
Edge
Session
Cntr
Session BGW:• Firewall Pinhole Control
• NAT
Signalling
• Bandwidth
management of media
• Packet Market Policing
streamBorder
virtual pipeSignalling Streams
G/W
IP N/W(s)
Edge
Session
Cntr
Signalling
Border
G/W
Session
Session
Data
BGW:Border QoS Media Streams Border
• To defined for each service
G/W
G/W
Data
Border
G/W
B/W
Mangt
Data
Other Service Streams Border
G/W
IP N/W(s)
Multi-Service IP Interconnect Functional Model
Transport
NGN A
Mangmt
Management
Flows
NGN B
Mangmt
Management Plane
Control Plane
B/W
Mangt
Control Plane
Bearer Plane
IP N/W(s)
MM -> SIP
Edge
Session
Cntr
Edge
Session
Cntr
PSTN -> SIP-I
Signalling
Border
G/W
Session
Border
G/W
Data
Border
G/W
Signalling Streams
Signalling
Border
G/W
QoS Media Streams
Session
Border
G/W
Other Service Streams
Data
Border
G/W
B/W
Mangt
IP N/W(s)
Multi-service NNI Transport Requirements
Adaptation of
service signal to
NNI signal
Termination
of NNI trail.
(Used for
monitoring)
Physical
connection
NNI
NNI signal
mux/switch
Service 1
Service 1
Service 2
Service 2
Service N
Service N
Supports:
1. Multiple NNI physical connections.
2. Resilient physical connections
Loosely using terminology & symbols from G.805/9.
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!
Example of this
function is a
border gateway
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
Sig.
PSTNoIP
Media
PSTNoIP
Sig.
Sig. F/W
Service N
Breaks if Service N = Ethernet already
using QinQ! Use MAC in MAC instead?
Breaks if Service N = SDH VCs!
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!
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
Sig.
PSTNoIP
Media
PSTNoIP
Sig.
Sig. F/W
Service N
ISSUES:
1.
Interworking GFP from different vendors?
2.
Cost of GFP capable SDH kit?
3.
UBR/VBR/AF type QoS not supported
efficiently – may waste bandwidth on NNI.
May only be an issue if:
1.
NNI is long distance.
2.
A majority of services bandwidth is
heavily contended UBR/VBR/AF.
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!