Packet Voice Core Design

Packet Voice Backbone
Network Design
Matt Kolon
February 23rd, 2004
APRICOT 2004 - Kuala Lumpur
Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 1

Agenda
 Packet voice essentials
• Quick background: VoIP Applications
• Customer Goals for Voice
• VoIP Traffic Characteristics
 Packet voice backbone design
• Class of service
• High Availability
• MPLS

Business: IP Voice Trunking
 Service Provided: Point-to-Point “IP trunk” with low-latency QoS
and guaranteed bandwidth. Usually to replace a pure FR service.
 SP implements it with circuit-oriented access network(s) and a
Traffic Engineered MPLS tunnel in the IP/MPLS backbone
 All VoIP “application” intelligence resides in enterprise private
devices (e.g. IAD/Media Gateway, IP PBX, SIP phones, etc)
Enterprise HQ IP trunk
Enterprise
Remote Site
MPLS LSP
FR/TDM DSLAM
IP PBX IAD POTS
SIP ATM
ETH/VLAN
IP/MPLS

Business: [Vo]IP transport VPNs
 Service Provided: Multipoint IP VPN with low-latency QoS and
guaranteed bandwidth, suitable for voice traffic. Often part of a multi
traffic class IP VPN offering (VoIP being only one traffic class).
 SP implements it with circuit-oriented access network(s) and a mesh of
Traffic Engineered MPLS tunnels in the backbone. Or pure Diffserv
approach with traffic trend monitoring. Or Layer 2 VPLS. Or IPSec…
 All VoIP “application” intelligence resides in enterprise private devices
Enterprise
(Vo)IP VPN Remote Sites
Enterprise HQ
DSLAM IAD POTS

FR/TDM
IP PBX
SIP DSLAM ETH/VLAN

IP VPNs
IAD POTS

Business: IP VPNs + Managed VoIP
 Service Provided: Multipoint IP VPN with low-latency QoS and guaranteed
bandwidth; Managed VoIP equipment in customer premises.
 SP implements it with circuit-oriented access network(s) and a mesh of Traffic
Engineered MPLS tunnels in the backbone. Or pure Diffserv approach with traffic
trend monitoring. Or Layer 2 VPLS. Or IPSec. Or private line (e.g. FR) links. Etc.
 All VoIP “application” intelligence resides in managed devices (e.g. IAD/Media
Gateway, IP PBX, etc) located in customer premises.
IP Telephony
Enterprise
(Vo)IP VPN Remote Sites
Enterprise HQ
DSLAM IAD POTS

FR/TDM
IP PBX
SIP DSLAM ETH/VLAN

IP VPNs
IAD POTS

Business: TDM/telephony, VoIP core
 Service Provided: regular TDM Telephony (transport and application)

 SP implements it with a TDM access network, Media Gateways, an IP Core, a
PSTN core, and PSTN mediation mechanisms. This is a Class 4/5
replacement application, not directly visible to the end users.
 VoIP “application” intelligence (servers and gateways) hosted by the SP,
overlaid on IP backbone, coupled with PSTN “intelligence”.
Enterprise Site 1 TDM / Telephony TDM / Telephony Enterprise Site 2
IP/MPLS
POTS GE MPLS LSP GE
TDM TDM POTS

CSU/DSU
TDM PBX
TDM TDM
Softswitch
SIP Softphone
PSTN/SS7

Carrier: signaling transport
 Service Provided: IP VPN to convey IP-based signaling & control

messages (SS7-over-IP, SIP, H.323, MGCP/Megaco, TCAP/IN, etc) with
proper CoS and insulation.
 SP implements it with an IP/MPLS Core. Could be operated by the voice
carrier, or outsourced to an IP provider.
 VoIP “application” intelligence
(servers and gateways) hosted
by the SP, overlaid on IP
backbone, coupled with PSTN Media Softswitch Class 4/5
intelligence. Gateway
Signaling
IP/MPLS

Carrier: inter-domain VoIP peering
 Service Provided (to end users): public telephony (VoIP or POTS)
 Main goal is to create a VoIP peering point between carriers
 SP implements it with “virtual” IP-to-IP gateways, plus inter-domain
signaling (e.g. SIP or SS7). May require true media/codec transcoding, or
“simple” IP forwarding.
 Complex business peering issues are addressed by the signaling layer.
IP-to-IP
“Virtual”
Gateways
IP/MPLS IP/MPLS
MPLS LSPs MPLS LSPs
SIP/H.323 Softswitch Softswitch SIP/H.323

Gatekeeper Gatekeeper
Peering Signaling

Business: IP Centrex, Softswitch
 Service Provided: IP Centrex (a.k.a. Hosted IP Telephony) to Small &
Medium VoIP-enabled Businesses.
 SP implements it with a broadband access network(s), a VPN enabled
IP/MPLS backbone, softswitches with Centrex intelligence, and PSTN
gateways (transport & signaling).
 All VoIP “application” intelligence is hosted by the SP, as well as PSTN
gateway mechanisms. “Virtual PBX”
IP Centrex
Enterprise Site
IP VPN
SIP
Sig. Gateway
MG Modem
DSLAM SS7
Softswitch
PSTN
FR/TDM IP/MPLS with VPNs Media Gateway
POTS

Residential: VoIP / telephony
 Service Provided: regular telephony services (transport and application),
via VoIP, in addition to regular Broadband Internet.
 SP implements it with a broadband access network, an IP/MPLS Core, a
PSTN core, and PSTN mediation mechanisms.
 VoIP “application” intelligence hosted by the SP, overlaid on IP
backbone, and coupled with PSTN “intelligence”
 CPE could be a mere bridge, or an IP router, or a full-blown media
gateway (POTS phones). Home network could be ETH, WLAN, etc.
Household/SOHO INTERNET Household/SMB
IP / Telephony IP / Telephony
IP/MPLS
CPE CPE
MPLS LSP (hierarchical)
SIP or DSLAM DSLAM

H.323 SIP or
H.323
POTS CMTS CMTS POTS

Softswitch
PSTN/SS7

Agenda
• MPLS

Goals for Packet Voice Networks
 Quality
• Deliver a grade of voice service equivalent to that
provided by the current Public Switched
Telephone Network (PSTN).
 Multiservice
• Voice service must live on a common IP backbone
with a set of other services.
 Flexibility
• Must be capable of supporting future applications
that may not yet be fully defined.

Quality: MOS Model
 Voice quality in the PSTN network has historically
been measured using ‘mean opinion score’ (MOS).
 The mean opinion score measures the subjective
quality of a voice call.
 Historically the telephony providers invited people
and used various call types (with delay, echo etc.) and
recorded the results.
 MOS scores for “acceptable” voice have been
dropping, but quality is still important.

Quality: Voice-worthy IP Backbones
 Sufficient bandwidth for voice + other services
 Delay: Less than 40msec
 Jitter: Less than 20msec
 Loss: Less than 2%
 Availability: Better than 4 9s, less than 1% blocking
 Security: No unauthorized intrusion or DoS effects
 Predictability: None of this changes in unforseeable ways

Engineering VoIP Experience Levels
Carrier-Grade
Over-Provisioned Over-Subscribed
Multi-Service
Network Network
Network
Best Effort Enhanced Delivery Assured Experience
Experience Levels
None (State-less) Planning/Reporting (Historical) Reactive (Real-time)
Service Level State
Best Effort Diff-Serv MPLS (Core) / Static (Access) MPLS (Core) / Dynamic (Access)
QoS
Flat Access / Core Integrated End-to-End
Network Resources

Core Domain VoIP Solutions
Over-Provisioned
Network
Core
Access Best Effort Access

Core Domain VoIP Architecture
Best Effort
 A Best Effort Experience is achieved by transporting voice over IP networks

without special treatment
• All packets delivered according to equal prioritization router queuing
throughout network
 Best effort engineered networks require over-provisioning to account for peak
traffic bursts associated with data applications and busy voice hours
 Studies and experience both show that today’s well engineered over-
provisioned networks based on current routing technologies can support most
voice services

Best Effort
Failure Detection ~ 300 ms – 1+ sec (without optimizations)

Route Convergence ~ 10+ sec (area size dependant)
Causes temporary service interruption, degradation of capacity
Router
Failure

Best Effort
Routing protocols unable to detect route around congestion


Link
Congestion

Best Effort – Pros & Cons
Pros
 Inexpensive Cons
 Simple  Performance levels not
maintainable across failures
 Studies show that over- and congestion
provisioning provides satisfactory
delay and jitter performance  Not adequate for over-
 Sufficient strategy for voice-only subscribed networks
and over-provisioned networks
 Challenges inherent with
building over-provisioned
networks
 Does not provide admission
control constructs

Over-Subscribed
Network
Core
Access Enhanced Delivery Access
Differentiated Services

Enhanced Delivery
 Differentiated Services (Diff-Serv) facilitates the ability to
provision separate service classes such that they receive
particular treatment levels
 Packets marked accordingly before entering the network
 Participating routers process packets according to Diff-Serv
marking
 Router Diff-Serv processing variables
• Queuing (priority levels)
• Scheduling (strict, weighted, round-robin, etc)
• Congestion avoidance (RED, WRED)

Enhanced Delivery
 DiffServ markings (DSCP) scale well
 DSCP’s can be AS-Dependant
• Router DSCP mediation requirement
 DSCP may be mapped to other QoS technologies across
network
• QoS migration
• Network segment QoS interworking
 DiffServ adds deterministic behavior to packet class transport
• This benefit enhances transport behavior in secondary path
re-route optimizations

Enhanced Delivery
•Cycle through output •Queuing schedulers

queues emptying from High Priority Queue typically allow for variable
highest to lowest priority weighting/emptying
Medium Priority Queue
•DiffServ markings map to Low Priority Queue •Queue sizes typically
queue level variable/provisionable

Enhanced Delivery
Failure Detection ~ 300 ms – 1+ sec (without optimizations)

Route Convergence ~ 10+ sec (area size dependant)
Re-Route performance doesn’t benefit from DiffServ treatment
Router
Failure

Enhanced Delivery
Routing protocols unable to detect route around congestion

High-priority-marked VoIP flows will take longer to be affected by
congestion than lower priority flows
May cause temporary VoIP service interruption, degradation of
capacity, will affect other services

Link
Congestion

Enhanced Delivery – Pros & Cons
Pros Cons
 Adequate for over-subscribed  Performance levels not
networks guaranteed across failures and
congestion
 Enhanced flow treatment for
VoIP across failure re-route  Link bandwidth statistics not
paths maintained or usable
 Lowers per-router hop latency  Does not enable admission
 Adds flow-based traffic control constructs
engineering model
 Scales easily

Carrier-Grade Multi-
Service Network
Core
Access Assured Experience Access
MPLS-TE

Assured Experience
 Assured Experience networks are built upon an
intelligent network resource plane
 Allow the service provider to guarantee deterministic
performance to its customers under all network
conditions
• Even during network congestion and element
failures
 Facilitate multi-service network infrastructures

Assured Experience
 The Intelligent Network Resource Plane…
• Maintains resource state, such as
• Link Bandwidth – up/down, total and current allocation
• Facilitates connection-oriented traffic engineering constructs, such

as…
• Constraint Based Routing Control
• Flow Classification and Forwarding
• Supports fault tolerance constructs, such as

• Fail-over Resources – routes, network elements

Assured Experience – MPLS
 MPLS supports the requirements of Intelligent
Network Resource Plane
 MPLS was designed to ease the provisioning and
maintenance of efficient packet data networks
 IGP and BGP routing protocols building forwarding
tables based on shortest path only
 MPLS separates the route control and packet
forwarding such that policy-based paths may be
constructed

 MPLS is based on…
• Label Switched Paths (LSP)
• Link Attribute Distribution (IGP/BGP protocol extensions)
• Traffic Engineering Databases (TED)
• Constrained-Shortest-Path-First Algorithm (CSPF)
• Label Distribution Protocols (LDP)
• Label Edge Routers (LER) and Label Switch Routers
(LSR)
 MPLS-TE facilitates constraint-based routing
 We’ll talk more about MPLS items later…

Assured Experience – MPLS Route Protection
 Primary LSP / Secondary LSP Configuration

• Allows for backup physical path TE
 Fast Rerouting
• Facilitates dynamic routing around link / node failures
 Fate Sharing
• Limit backup LSP crossing of the same physical elements
as primary LSP

•Traffic Engineering creates LSP’s

•Labels are distributed to construct LSP’s
LER LSR LER
•Packets are classified / Labels added •LSR’s only inspect label •Label is removed from packets
•L2/L3 policy application •Label and interface table lookup •Packets are routed to destination
•Upstream flows policed, downstream •Output label and interface

flows shaped
•Queue and drop accordingly

Failure Detection ~ 20 – 30 ms
Fast Reroute < 50 ms
Small amount of packet loss during failover
Service interruption not noticeable, minimal capacity degradation
Router
Failure

Assured Experience – Pros & Cons
Pros Cons
 State-full, intelligent network  Fully meshed topologies
resource plane suffer from n2 scaling issues
 Designed to ease TE design,
maintenance and management
 Facilitates class-based forwarding
for multi-service networks
 Interworks with disparate QoS
mechanisms and transport
technologies
 Supports hierarchical forwarding

Multiservice: Service Classes
 From this… To this….
Control Data Control Internet Voice VPN
 Easy to think of as “CoS”, but actually involves much

more than traditional router CoS or QoS mechanisms.

Multiservice: Bundled Service Offerings
 Plain VoIP service model is proven to be non-sustainable
• First generation of pure VoIP carriers are gone
• Price of 1 min of voice has fallen through the floor
 VoIP with other services is the way to go
• Value-add: Unified messaging, voice accessible content,
video telephony
• Additional non-voice: Broadcast video, surveillance, etc.
VPNs and other business services
• Generate more revenue, key differentiator from competitors
• Can be offered at minimum additional cost

Final Thought on Goals:
Who Really Knows?
 Future service revenue
• By definition unknowable, will always surprise us…
• Immense possibility in diverse areas such as mobile,
micropayment, handheld videoconferencing…
• Infrastructure must have:
• Unrestricted future service rollout
– Vendors must design flexible hardware and software platforms
• Upgradeable without forklift
• Capability to support many services at one time, without the
services affecting each other

Agenda
• MPLS

QoS: Bandwidth
 VoIP traffic is constant bit stream, bandwidth required

varies with which codec used, # of voice sample per
packet, and transport media used.
 Even G.711 packets are only ~80 bytes, each call only
~112 kbps.
 VoIP packet is very small for compressed codecs
• G.729 with two 10ms samples/frame yields 24Kbps
without layer2 headers
 Line rate processing of VoIP packets is crucial!

QoS: Delay
 ITU G.114: <150ms for one-way, e2e
 Delay Budget:
• T f Packet formation delay, O(10ms)
• Tsf Packet switching delay, O(10us) per Hop
Si
• Serialization delay, (#bits/link rate*#Hop)
Pi
• Q Propagation delay, (1ms/100mile)
max
• Queuing delay, (variable)

 typical backbone delay requirement: <30ms

QoS: Jitter
 Definition: Variations in packet arrival time
 Causes:
• Queuing variation under changing network load condition
• Load sharing over changing paths
 De-jitter (“playout”) buffer in gateways
• Static or dynamic
• Adds to the overall delay
 Best to avoid causes of Jitter rather than trying to buffer it away.

QoS: Packet Loss
 UDP as transport
• no flow control
• doesn’t tolerate packet loss very well
 <1% to avoid quality degradation
 <5% if VoIP gateway provides concealment
mechanism
 Higher compression rates demand lower loss budgets

Network Availability & Recovery
 Availability
• Common SLA for VoIP network: 99.995% or 26 min/yr
• Availability needs continue to increase
 Recovery
• O(sub-second) to avoid session timeout and new call setup
• VoIP gateway to gateway recovery usually spans over
several segments
• Layer 3 based network recovery is generally unacceptable

Network Security
 Guard against un-trusted network elements and network-
level attacks
 Stateful and stateless firewall capabilities may be necessary
 Authentication to Prevent Fraud
• RADIUS most common deployment
 Confidentiality is emerging as another basic security
requirement for VoIP
• Carry VoIP traffic within VPN, such as IPsec tunnel or
MPLS VPN
• Increased security vs. encryption overhead for VoIP
packet

Agenda
• MPLS

Topological Assumptions
 Routers deployed in pairs at each site
• Primarily for fault tolerance
• Also useful for load sharing
 Intra-site connections required in all topologies
• Must be at least same capacity as inter-site trunk
links

Core Topologies
 Star-connected Core
• “Outer core”
connected
to two
“super-routers”
• Simple routing and
forwarding
• Probably least
expensive
• Concerns about redundancy

Core Topologies
 Fully-connected Mesh
• Each router connected
to every other site
• Also simple routing and
forwarding
• Perhaps most
expensive
• Mesh can always
be reduced!

Core Topologies
 Half-mesh router groups
• Each router connected
to ~half of other sites
• More complex routing
and forwarding
• Many full-mesh benefits
without the expense
• Success depends on
engineering to
particular needs

Edge-core Topologies 1
 Single uplink per router edge site
• Two connections
to two routers in one
core site Core
Router
• Availability largely Site 1
dependent on physical
Edge
Router
layout
Site D
Core
Router
• Usually lowest cost

Site 2

 Single uplink per router edge site
• Two site connections
to two separate
routers Core
Router
• Availability depends on Site 1
physical media Edge
Router
• Somewhat low cost Site C

Core
Router
Site 2

 Partially duplicated edge router uplinks
• Three connections
to three separate
routers Core
• One dual-homed,
Router
Edge
Site 1
one not Router

Site B
• Particularly useful in Core
MPLS topologies Router
Site 2
• High availability
• Somewhat high cost

 Fully duplicated edge router uplinks
• Four connections
to four separate
routers Core
Router
Site 1
• Both edge routers
Edge
Router
dual-homed
Site A
• Highest availability
Core
Router
Site 2
• Highest cost

Site Connection to Edge Routers
 Many variants on dual-homed
designs possible
 Essential idea is suitable
for gateway or
softswitch sites
primary gatew
Media „active“ L2interface
switching
interface
„standby“
Gateways
 Best-effort traffic
may enter
through separate
PCUs
backb
aggregation secondary gate
points

IGP Selection
 Two options:
• ISIS
• OSPF
 Very close race!
 Biggest issue is probably legacy deployment in current
network, and customer comfort.
 ISIS has slight edge in terms of sub-second failure detection
 Main point is that a successful network can be built with
either.

IGP Configuration
 Issues to consider
• Hierarchy (areas or levels)
• Hello Timers
• BFD changes things here!
• Authentication for security
• Addressing plan
• ISIS requires ISO NET lo0 addresses
• Metrics
• Load balancing

Load-balancing Considerations
 Two approaches to load balancing
• Per-destination
• Single path chosen from equal-cost next hops
• Simpler to predict
• Per-flow
• Flow distributed between equal-cost next hops
• Policy can restrict potential traffic path
 Choice depends primarily on topology and other requirements
 Most voice engineers more comfortable with per-destination

Forwarding Protection Protocol Options
 Link Redundancy
• MLPPP – T1/E1 Link aggregation
• 802.3ad – Ethernet aggregation
• SONET/SDH aggregation
 SONET/SDH APS/MPS
 Virtual Router Redundancy Protocol (VRRP)
 Standard IGP protocols
• OSPF
• ISIS
 Bidirectional Forwarding Detection (BFD)

Bidirectional Forwarding Detection (BFD)
 IETF Draft co-authored by Juniper and Cisco
 Optimized timer-based link failure detection protocol
• Brings link failure detection in line with today’s high-speed
transport technologies
 Reduces link failure recognition from seconds to 10’s of
milliseconds
• Provisionable for link/service requirements
 Operates at packet forwarding plane
• Independent from routing protocols and applications
 When run between edge router and media gateway, provides
network resource to VoIP service link

MG to Router Connection with BFD
Cards
BFD-A1
Line
Line Cards BFD-B1 BFD-B2
VoIP
BFD-A2
BFD-A1bu
BFD-B1bu BFD-B2bu
MG
Cards
Line
BFD-A2bu
 VoIP Line Card Failure

• Connectivity of A1 protected by B1 (vice-versa)
• Call preserved only under specific MG application control
 Router PIC Failure

• Connectivity of A1 and B1 protected by A2 and B2 respectively (vice-versa)
• Call preserved with packet-loss period (dependant on detection and re-route times)
 Router System Failure

• Connectivity of A and B protected by Abu and Bbu respectively (vice-versa)

Agenda
• MPLS

IP CoS Functions
Traffic
Per-flow Rate Priority Congestion
Classification
Policing Queuing Avoidance
&
Marking
W
R
R
RED
• IP Flow
• IP Precedence bits, DSCP Byte
100%
• MPLS CoS bits Stream
• Incoming Physical Interface
• Incoming Logical Interface
• Destination IP address
100% 100%
PLP=1 PLP=0

Converged Network CoS Design
 In a voice / best effort network, three classes (at least) of service are
necessary:
• IP network control traffic
• Low bandwidth requirements, not sensitive to latency, jitter
• Must not be starved
• Voice signaling and bearer traffic
• Highest latency and jitter requirements
• Best effort data traffic
• Whatever capacity is left
 More complex configurations may or may not be needed in other
network designs (e.g. with VPN service)
 More classes = more complexity, no way around this.

Queue 0 : IP Network Control traffic

• Allocated bandwidth : 5% (the default for
NC)
• Priority: High; this guarantees that NC
traffic will never be starved of bandwidth.
• No RED drop profile assigned, as NC traffic
should never be dropped.

Queue 3 : Voice Signaling and Bearer traffic
• Initial requirement is 50% of total traffic.
• Allocated bandwidth: 20%; although doesn’t really
matter as this queue gets strictly high priority.
• Strictly High Priority: voice can take as much
bandwidth as it needs.
 RED drop profile: drop nothing until queue is full, then
drop everything.
• Dropping packets randomly is not very suitable on
voice traffic.
• Forces head dropping (rather than tail dropping)
once queue is full.

Queue 1 : Best effort
• Allocated bandwidth: remaining 75%.
• Not guaranteed
• Priority: Low; this traffic is served only if there is no
voice traffic, and there is bandwidth available.
• RED drop profile: medium. This can be fine tuned,
perhaps start to drop when queue is 70%, with a
probability of 30%, then drop 100% of the traffic
when queue fullness reaches 90%.
• Medium RED drop profile will limit the TCP
congestion synchronization phenomena that would
occur otherwise.

More Services Possible!
 Multiservice queuing
• Service VoIP Queue Aggressively to Avoid Filling the Queue
Best Effort Traffic Queue 0 = 50% WRR Service Rate = 15%
VPN Traffic Queue 1 = 35% WRR Service Rate = 15%
VoIP Traffic Queue 2 = 10% WRR Service Rate = 65%
Network Control Queue 3 = 5% WRR Service Rate = 5%

Traffic

Agenda
• MPLS

Don’t Stop Sending the Voice!
 It doesn’t matter what happens otherwise…
• Customers only notice when the call is interrupted
 Many call this idea “Non-Stop Forwarding”
 Main Principles of NSF
• Data Plane should not be disrupted
• Control plane failures should not effect forwarding
• Failures happen but the infrastructure can recover gracefully
• Management/Routing sessions can be re-connected unnoticed
 Many Vendors Adopting this approach
• Not all, some favor fully redundant protocol state mirroring

Graceful Restart - How ?
 Restarting node preserves the forwarding state
 Control plane failure known only to the Routing peers
 Routing peers preserve routing information of restarting node
 Restarting node (re)learns its routing information from its
routing peers
 No preservation of any of the protocol-related state across the
restart on restarting node

Graceful Restart - How ?
Separate control
When router recovers,
and data planes
P P neighbors sync up
without disturbing
PE 2 forwarding.
PE 1
If router’s control
plane fails, data PE 3
plane can keep P P
forwarding packets
Neighbors hide Other routers
failure from all are never made
others routers aware of failure
in the network

Graceful Restart - How ? (cont.)
 Graceful restart mechanisms are protocol specific:
• BGP for Interdomain routing
• ISIS and OSPF for IGPs
• LDP and RSVP for LSP management
• BGP/MPLS specific to MPLS VPN management
• RIP – already built in, but a draft nonetheless
 All these are currently IETF drafts, but implemented by major vendors
 (this isn’t an unusual situation, many examples of this these days)

Hitless RE Switchover
 Protects against Single Node Hardware Failure
 Primary (REP) and Secondary (RES) utilize
keepalive process
Keep • Automatic failover to RES
Alive
Routing Engines • Synchronized Configuration
 REP and RES share:
• Forwarding info + PFE config
 REP failure does not reset PFE
Packet Forwarding • No forwarding interruption
Engines
• Only Management sessions lost
• Alarms, SNMP traps on failover

Agenda
• MPLS

IP-only Path Selection
 Largely dependent on routing protocols
 Adjustable only through metrics
• Changes tend to be global
• Difficult on per-application basis
• Extremely manual and labor-intensive in nature
• Requires offline path computation

IP-only Network Reliability Mechanisms
•Connection-oriented transport (TCP)
•Not used for realtime traffic like voice
•Dependence on underlying network infrastructure
•E.g. SONET/SDH APS, Ethernet VRRP, ATM
•Not IP-based, therefore not network-wide
•Routing protocol recovery
•Relatively slow convergence
•Potential system-wide effects
•BFD improves this, but not enough by itself

Enter MPLS
•Low-overhead virtual circuits for IP!
•Gives many Voice-friendly attributes to IP
•DiffServ-compatible CoS
•Deterministic path selection
•Failure recovery via:
•Fast reroute
•Secondary LSPs
•Planning and determinism through circuit-like
traffic engineering

MPLS-TE network optimization
label-switched-path HK_to_Tokyo {
•Traffic engineering to Tokyo;
from Hong_Kong;
allows deterministic admin-group {exclude red}
paths for Voice and other cspf}
realtime data, similar to

Seoul Tokyo
circuit switched networks
Hong Kong
•Constraint-based routing Taipei
can dynamically choose
paths best suited to Kuala Lumpur
applications or types of
Manilla
traffic
Singpore
Jakarta

MPLS CoS Capabilities
•EXP field (and label) can be used for CoS
Label (20-bits) CoS S TTL
L2 Header MPLS Header IP Packet
32 bits
•DiffServ-compatible
•Consistent meanings can exist for MPLS EXP
(and label) and IP DiffServ per-hop behaviors
•Core (MPLS) and edge (IP/DiffServ) PHBs can be
related and consistent

What is Diff-Serv TE ?
 Diff-Serv: scheduling/queueing behaviour at each node depends on traffic type
(indicated by DSCP/EXP setting)
 MPLS TE: use of constraints to control placement of LSPs. Typically, various traffic
classes share the same LSP. Bandwidth reservations do not take account of the classes
of traffic involved.
 MPLS Diff-Serv TE:
• Traffic divided into up to eight Class-Types.
• CSPF and RSVP take the Class-Type into account when computing path of LSP.
• Results in More granular bandwidth reservation.
 On each link in network, can have separate bandwidth constraints for each type of
traffic
• E.g. limit the bandwidth taken by voice LSPs on a link to a maximum of 40%,
data LSPs take the rest.

CoS / QoS & Forwarding
 Diff-Serv-aware MPLS Traffic Engineering
 Guaranteed bandwidth for MPLS
• Combines MPLS Diffserv and Diffserv TE
• Provides strict point to point QoS guarantees
Aggregated State (DS)

Aggregate Admission Control (DS-TE)
Aggregate Constraint-based Routing (DS-TE)
No state Aggregated state Per-Flow state
MPLS Diff-Serv +
MPLS DS-TE
Best effort Diff-Serv RSVP v1
MPLS & Int-Serv
Guaranteed
Bandwidth

How DS-TE Operates
 Operations Performed by the

Extended IGP Ingress LSR
Traffic Engineering Constrained User

Routing Table
Database (TED) Shortest Path First Constraints
1) Store information from IGP flooding

2) Store traffic engineering information Explicit Route
3) Examine user defined constraints

4) Calculate the physical path for the LSP
RSVP Signaling
5) Represent path as an explicit route

MPLS failure recovery
•Fast reroute allows rapid switching to alternate link
segments while longer-term repairs are made
•Secondary LSPs provide deterministic alternate
paths during link failure
•Possible in a consistent, network-wide manner

MPLS Fast Reroute
Single user command
at head end to enable
Fast Reroute.
Detour Detour Detour
Primary Primary Primary Primary
LSR1 LSR2 LSR3 LSR4 LSR5
• Fast reroute is signaled to each LSR in the path

• Each LSR computes and sets up a detour path
that avoids the next link and next LSR
• Each LSR along the path uses the same route
constraints used by head-end LSR

MPLS Fast Reroute:Recovery Times
400
350
MSeconds
300
250
200 Max
150 Average
100 Min
50
0
5.0 5.1 5.2 5.3+
JUNOS version

Summary
•VoIP deployments are going ahead

•Good for provider profits
•Good for customer services and needs
•The question is no longer “if”, but rather “how”
•Luckily:
•There are tools that make voice backbones
•Possible
•High-quality
•Profitable
•Diff-serv, NSF, and MPLS are up to the job

Thank You

Packet Voice Core Design

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Packet Voice Core Design

Diunggah oleh

Hak Cipta:

Format Tersedia

Packet Voice Backbone

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 1

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 2

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 3

DSLAM IAD POTS

SIP DSLAM ETH/VLAN

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 4

DSLAM IAD POTS

SIP DSLAM ETH/VLAN

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 5

 Service Provided: regular TDM Telephony (transport and application)

POTS GE MPLS LSP GE

TDM TDM POTS

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 6

 Service Provided: IP VPN to convey IP-based signaling & control

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 7

MPLS LSPs MPLS LSPs

SIP/H.323 Softswitch Softswitch SIP/H.323

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 8

FR/TDM IP/MPLS with VPNs Media Gateway

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 9

SIP or DSLAM DSLAM

POTS CMTS CMTS POTS

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 10

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 11

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 12

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 13

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 14

Best Effort Enhanced Delivery Assured Experience

None (State-less) Planning/Reporting (Historical) Reactive (Real-time)

Service Level State

Flat Access / Core Integrated End-to-End

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 15

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 16

 A Best Effort Experience is achieved by transporting voice over IP networks

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 17

Failure Detection ~ 300 ms – 1+ sec (without optimizations)

Routing protocols unable to detect route around congestion

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 19

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 20

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 21

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 22

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 23

•Cycle through output •Queuing schedulers

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 24

Failure Detection ~ 300 ms – 1+ sec (without optimizations)

Routing protocols unable to detect route around congestion

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 26

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 27

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 28

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 29

• Facilitates connection-oriented traffic engineering constructs, such

• Supports fault tolerance constructs, such as

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 30

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 31

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 32

 Primary LSP / Secondary LSP Configuration

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 33

•Traffic Engineering creates LSP’s

LER LSR LER

•Upstream flows policed, downstream •Output label and interface

Copyright © 2003 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 34