juniper networks presentation template-emea

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

Packet Voice Backbone Network

DesignMatt Kolon

February 23rd, 2004

APRICOT 2004 - Kuala Lumpur

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

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

IP PBX

Enterprise HQ EnterpriseRemote Site

IAD POTS

SIP

Service Provided: Point-to-Point “IP trunk” with low-latency QoS Service Provided: Point-to-Point “IP trunk” with low-latency QoS and guaranteed bandwidth. Usually to replace a pure FR service.and guaranteed bandwidth. Usually to replace a pure FR service.

SP implements it with circuit-oriented access network(s) and a SP implements it with circuit-oriented access network(s) and a Traffic Engineered MPLS tunnel in the IP/MPLS backboneTraffic Engineered MPLS tunnel in the IP/MPLS backbone

All VoIP “application” intelligence resides in enterprise private All VoIP “application” intelligence resides in enterprise private devices (e.g. IAD/Media Gateway, IP PBX, SIP phones, etc)devices (e.g. IAD/Media Gateway, IP PBX, SIP phones, etc)

IP trunk

ATM

FR/TDM DSLAM

IP/MPLS

MPLS LSP

ETH/VLAN


Business: [Vo]IP transport VPNs

IP PBX

Enterprise HQ

EnterpriseRemote Sites

IAD POTS

SIP

Service Provided: Multipoint IP VPN with low-latency QoS and Service Provided: Multipoint IP VPN with low-latency QoS and guaranteed bandwidth, suitable for voice traffic. Often part of a multi guaranteed bandwidth, suitable for voice traffic. Often part of a multi traffic class IP VPN offering (VoIP being only one traffic class).traffic class IP VPN offering (VoIP being only one traffic class).

SP implements it with circuit-oriented access network(s) and a mesh of SP implements it with circuit-oriented access network(s) and a mesh of Traffic Engineered MPLS tunnels in the backbone. Or pure Diffserv Traffic Engineered MPLS tunnels in the backbone. Or pure Diffserv approach with traffic trend monitoring. Or Layer 2 VPLS. Or IPSec…approach with traffic trend monitoring. Or Layer 2 VPLS. Or IPSec…

All VoIP “application” intelligence resides in enterprise private devicesAll VoIP “application” intelligence resides in enterprise private devices(Vo)IP VPN

POTSIAD

DSLAM

FR/TDMDSLAM

ETH/VLANIP VPNs


Business: IP VPNs + Managed VoIP

IP PBX

Enterprise HQ

EnterpriseRemote Sites

IAD POTS

SIP

Service Provided: Multipoint IP VPN with low-latency QoS and guaranteed Service Provided: Multipoint IP VPN with low-latency QoS and guaranteed bandwidth; bandwidth; ManagedManaged VoIP equipment in customer premises. VoIP equipment in customer premises.

SP implements it with circuit-oriented access network(s) and a mesh of Traffic 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 Engineered MPLS tunnels in the backbone. Or pure Diffserv approach with traffic

trend monitoring. Or Layer 2 VPLS. Or IPSec. trend monitoring. Or Layer 2 VPLS. Or IPSec. Or private line (e.g. FR) links. Etc.Or private line (e.g. FR) links. Etc.

All VoIP “application” intelligence resides in managed devices (e.g. IAD/Media All VoIP “application” intelligence resides in managed devices (e.g. IAD/Media Gateway, IP PBX, etc) located in customer premises.Gateway, IP PBX, etc) located in customer premises.

(Vo)IP VPN

POTSIAD

DSLAM

FR/TDMDSLAM

ETH/VLANIP VPNs

IP Telephony


Business: TDM/telephony, VoIP core

CSU/DSU

Enterprise Site 1 Enterprise Site 2

POTS

SIP

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

SP implements it with a TDM access network, Media Gateways, an IP Core, a 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 PSTN core, and PSTN mediation mechanisms. This is a Class 4/5 replacement application, not directly visible to the end users.replacement application, not directly visible to the end users.

VoIP “application” intelligence (servers and gateways) hosted by the SP, VoIP “application” intelligence (servers and gateways) hosted by the SP, overlaid on IP backbone, coupled with PSTN “intelligence”.overlaid on IP backbone, coupled with PSTN “intelligence”.

TDM / Telephony

TDM PBX

TDM / Telephony

Softphone

POTS

TDM

TDM

TDM

IP/MPLS

MPLS LSP GEGE

TDM

Softswitch

PSTN/SS7


Carrier: signaling transport

Service Provided: IP VPN to convey IP-based signaling & control Service Provided: IP VPN to convey IP-based signaling & control messages (SS7-over-IP, SIP, H.323, MGCP/Megaco, TCAP/IN, etc) with messages (SS7-over-IP, SIP, H.323, MGCP/Megaco, TCAP/IN, etc) with proper CoS and insulation.proper CoS and insulation.

SP implements it with an IP/MPLS Core. Could be operated by the voice SP implements it with an IP/MPLS Core. Could be operated by the voice carrier, or outsourced to an IP provider.carrier, or outsourced to an IP provider.

VoIP “application” intelligence VoIP “application” intelligence (servers and gateways) hosted (servers and gateways) hosted by the SP, overlaid on IP by the SP, overlaid on IP backbone, coupled with PSTN backbone, coupled with PSTN intelligence.intelligence.

Softswitch

Signaling

Class 4/5MediaGateway

IP/MPLS


Carrier: inter-domain VoIP peering

Service Provided (to end users): public telephony (VoIP or POTS)Service Provided (to end users): public telephony (VoIP or POTS)

Main goal is to create a VoIP peering point between carriersMain goal is to create a VoIP peering point between carriers

SP implements it with “virtual” IP-to-IP gateways, plus inter-domain 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 signaling (e.g. SIP or SS7). May require true media/codec transcoding, or “simple” IP forwarding.“simple” IP forwarding.

Complex business peering issues are addressed by the signaling layer.Complex business peering issues are addressed by the signaling layer.

IP/MPLS

MPLS LSPs

SoftswitchSIP/H.323 Gatekeeper

IP-to-IP“Virtual”

Gateways

IP/MPLS

MPLS LSPs

Softswitch SIP/H.323 Gatekeeper

Peering Signaling


SS7PSTN

Business: IP Centrex, Softswitch

Modem

Enterprise Site

POTS

Service Provided: IP Centrex (a.k.a. Hosted IP Telephony) to Small & Service Provided: IP Centrex (a.k.a. Hosted IP Telephony) to Small & Medium VoIP-enabled Businesses.Medium VoIP-enabled Businesses.

SP implements it with a broadband access network(s), a VPN enabled SP implements it with a broadband access network(s), a VPN enabled IP/MPLS backbone, softswitches with Centrex intelligence, and PSTN IP/MPLS backbone, softswitches with Centrex intelligence, and PSTN gateways (transport & signaling).gateways (transport & signaling).

All VoIP “application” intelligence is All VoIP “application” intelligence is hostedhosted by the SP, as well as PSTN by the SP, as well as PSTN gateway mechanisms.gateway mechanisms.

IP VPN

SIP

MG

IP Centrex

DSLAM

FR/TDM IP/MPLS with VPNs

Softswitch

Sig. Gateway

Media Gateway

“Virtual PBX”


Residential: VoIP / telephony

Household/SMB

Service Provided: regular telephony services (transport and application), Service Provided: regular telephony services (transport and application), via VoIP, in addition to regular Broadband Internet.via VoIP, in addition to regular Broadband Internet.

SP implements it with a broadband access network, an IP/MPLS Core, a SP implements it with a broadband access network, an IP/MPLS Core, a PSTN core, and PSTN mediation mechanisms.PSTN core, and PSTN mediation mechanisms.

VoIP “application” intelligence hosted by the SP, overlaid on IP VoIP “application” intelligence hosted by the SP, overlaid on IP backbone, and coupled with PSTN “intelligence”backbone, and coupled with PSTN “intelligence”

CPE could be a mere bridge, or an IP router, or a full-blown media 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.gateway (POTS phones). Home network could be ETH, WLAN, etc.

IP / Telephony

CPE

Household/SOHO

SIP orH.323

POTS CMTS

DSLAM

CMTS

IP/MPLS

MPLS LSP (hierarchical)

DSLAM

Softswitch

PSTN/SS7

INTERNET IP / Telephony

CPE

SIP orH.323

POTS


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


Over-ProvisionedNetwork

Over-SubscribedNetwork

Carrier-GradeMulti-Service

Network

Flat Access / Core Integrated End-to-End

Engineering VoIP Experience Levels

Best Effort Diff-Serv MPLS (Core) / Static (Access) MPLS (Core) / Dynamic (Access)

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

Network Resources

Experience Levels

QoS

Service Level State

Enhanced Delivery Assured ExperienceBest Effort


Core Domain VoIP Solutions

AccessAccess

Over-ProvisionedNetwork

Best Effort

Core


Core Domain VoIP ArchitectureBest EffortBest 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



RouterRouterFailureFailure

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

Route Convergence ~ 10+ sec (area size dependant)

Causes temporary service interruption, degradation of capacity



LinkLink

CongestionCongestion

Routing protocols unable to detect route around congestion



Core Domain VoIP ArchitectureBest Effort – Pros & ConsBest Effort – Pros & Cons

Pros

Inexpensive

Simple

Studies show that over-provisioning provides satisfactory delay and jitter performance

Sufficient strategy for voice-only and over-provisioned networks

Cons

Performance levels not maintainable across failures and congestion

Not adequate for over-subscribed networks

Challenges inherent with building over-provisioned networks

Does not provide admission control constructs



AccessAccess

Over-SubscribedNetwork

Enhanced DeliveryDifferentiated Services

Core


Core Domain VoIP ArchitectureEnhanced DeliveryEnhanced 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)



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



Medium Priority Queue

High Priority Queue

Low Priority Queue

•Cycle through output queues emptying from highest to lowest priority

•DiffServ markings map to queue level

•Queuing schedulers typically allow for variable weighting/emptying

•Queue sizes typically variable/provisionable




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

Route Convergence ~ 10+ sec (area size dependant)

Re-Route performance doesn’t benefit from DiffServ treatment




LinkLink

CongestionCongestion

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


Core Domain VoIP ArchitectureEnhanced Delivery – Pros & Enhanced Delivery – Pros &

ConsCons

Pros

Adequate for over-subscribed networks

Enhanced flow treatment for VoIP across failure re-route paths

Lowers per-router hop latency

Adds flow-based traffic engineering model

Scales easily

Cons

Performance levels not guaranteed across failures and congestion

Link bandwidth statistics not maintained or usable

Does not enable admission control constructs



AccessAccess Assured Experience MPLS-TE

Carrier-Grade Multi-Service Network

Core


Core Domain VoIP ArchitectureAssured ExperienceAssured 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


Core Domain VoIP ArchitectureAssured ExperienceAssured 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


Core Domain VoIP ArchitectureAssured Experience – MPLSAssured 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


Core Domain VoIP ArchitectureAssured Experience – MPLSAssured Experience – MPLS

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…


Core Domain VoIP Architecture Assured Experience – MPLS Route Assured Experience – MPLS Route

ProtectionProtection

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


Core Domain VoIP Architecture Assured Experience – MPLSAssured Experience – MPLS

LER

•Traffic Engineering creates LSP’s

•Labels are distributed to construct LSP’s

LSR LER

•Packets are classified / Labels added

•L2/L3 policy application

•Upstream flows policed, downstream flows shaped

•Queue and drop accordingly

•LSR’s only inspect label

•Label and interface table lookup

•Output label and interface

•Label is removed from packets

•Packets are routed to destination


Core Domain VoIP Architecture Assured ExperienceAssured Experience – MPLS– MPLS


Failure Detection ~ 20 – 30 ms

Fast Reroute < 50 ms

Small amount of packet loss during failover

Service interruption not noticeable, minimal capacity degradation


Core Domain VoIP ArchitectureAssured Experience – Pros & Assured Experience – Pros &

ConsCons

Pros State-full, intelligent network

resource plane

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

Cons

Fully meshed topologies suffer from n2 scaling issues


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:

• Packet formation delay, O(10ms)

• Packet switching delay, O(10us) per Hop

• Serialization delay, (#bits/link rate*#Hop)

• Propagation delay, (1ms/100mile)

• Queuing delay, (variable)

typical backbone delay requirement: <30ms

sfT

fT

iS

iP

maxQ


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” connectedto two “super-routers”

• Simple routing andforwarding

• Probably leastexpensive

• Concerns about redundancy


Core Topologies

Fully-connected Mesh

• Each router connectedto every other site

• Also simple routing andforwarding

• Perhaps mostexpensive

• Mesh can alwaysbe reduced!


Core Topologies

Half-mesh router groups

• Each router connectedto ~half of other sites

• More complex routing and forwarding

• Many full-mesh benefitswithout the expense

• Success depends onengineering to particular needs


Edge-core Topologies 1

Single uplink per router edge site

• Two connections to two routers in onecore site

• Availability largely dependent on physical layout

• Usually lowest cost

Core RouterSite 1

Core

Router

Site 2

Edge

Router

Site D



Single uplink per router edge site

• Two site connections to two separate routers

• Availability depends onphysical media

• Somewhat low cost

Core RouterSite 1

Core

Router

Site 2

Edge

Router

Site C



Partially duplicated edge router uplinks• Three connections

to three separate routers

• One dual-homed,one not

• Particularly useful inMPLS topologies

• High availability• Somewhat high cost

Edge RouterSite B

Core

Router

Site 1

Core

Router

Site 2



Fully duplicated edge router uplinks

• Four connections to four separate routers

• Both edge routersdual-homed

• Highest availability

• Highest cost

Core RouterSite 1

Core

Router

Site 2

Edge

Router

Site A


Site Connection to Edge Routers

Many variants on dual-homeddesigns possible

Essential idea is suitablefor gateway orsoftswitch sites

Best-effort trafficmay enterthrough separateaggregationpoints

„active“ interfaceprimary gateway

secondary gateway

„standby“ interfaceL2 switching

backbonePCUs

MediaGateways


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

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)

MG

VoIP

Lin

e C

ard

s

Lin

eC

ard

s

BFD-A1

BFD-B1 BFD-B2

BFD-A2

Lin

eC

ard

s

BFD-A1bu

BFD-B1bu BFD-B2bu

BFD-A2bu


Agenda








• MPLS


IP CoS Functions

WWRRRR

REDRED

PLP=0100%100%

PLP=1

Stream100%

• IP Flow

• IP Precedence bits, DSCP Byte

• MPLS CoS bits

• Incoming Physical Interface

• Incoming Logical Interface

• Destination IP address

Priority Priority QueuingQueuing

Traffic Traffic ClassificationClassification

& & MarkingMarking

Per-flow Per-flow Rate Rate PolicingPolicing

Congestion Congestion AvoidanceAvoidance


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.


WRR Service Rate = WRR Service Rate = 5%5%




More Services Possible! Multiservice queuing

• Service VoIP Queue Aggressively to Avoid Filling the Queue

Queue 0 = 50%Queue 0 = 50%

Queue 1 = 35%Queue 1 = 35%

Queue 2 = 10%Queue 2 = 10%

Queue 3 = 5%Queue 3 = 5%

VPN TrafficVPN Traffic

VoIP TrafficVoIP Traffic

Network Control Network Control TrafficTraffic

Best Effort TrafficBest Effort 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 ?

PP

PP

PP

PP

Separate controlSeparate control

and data planesand data planes

PE 1PE 1

PE 2PE 2

PE 3PE 3

Other routersOther routers

are never madeare never made

aware of failureaware of failure

Neighbors hideNeighbors hide

failure from allfailure from all

others routersothers routers

in the networkin the network

When router recovers,When router recovers,

neighbors sync upneighbors sync up

without disturbingwithout disturbing

forwarding.forwarding.

If router’s controlIf router’s control

plane fails, dataplane fails, data

plane can keepplane can keep

forwarding packetsforwarding packets


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

• Automatic failover to RES

• Synchronized Configuration

REP and RES share:

• Forwarding info + PFE config

REP failure does not reset PFE

• No forwarding interruption

• Only Management sessions lost

• Alarms, SNMP traps on failover

Keep AliveRouting

Engines

Packet Forwarding Engines


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

•Traffic engineering allows deterministic paths for Voice and other realtime data, similar to circuit switched networks

•Constraint-based routing can dynamically choose paths best suited to applications or types of traffic

Kuala LumpurKuala Lumpur

JakartaJakarta

ManillaManilla

TokyoTokyo

Hong KongHong Kong

SeoulSeoul

TaipeiTaipei

SingporeSingpore

label-switched-path HK_to_Tokyo {label-switched-path HK_to_Tokyo { to Tokyo;to Tokyo; from Hong_Kong;from Hong_Kong; admin-group {exclude admin-group {exclude red}red} cspf}cspf}


MPLS CoS Capabilities

•EXP field (and label) can be used for CoS

•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

TTLLabel (20-bits) CoS S

IP PacketIP Packet

32 bits32 bits

L2 HeaderL2 Header MPLS HeaderMPLS Header


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.


Diff-Serv-aware MPLS Traffic Engineering

Guaranteed bandwidth for MPLS• Combines MPLS Diffserv and Diffserv TE• Provides strict point to point QoS guarantees


MPLS Diff-Serv + MPLS DS-TE

Aggregated State (DS)Aggregate Admission Control (DS-TE)

Aggregate Constraint-based Routing (DS-TE)

MPLSGuaranteedBandwidth

No state Aggregated state Per-Flow state

Best effort Diff-Serv RSVP v1& Int-Serv

CoS / QoS & Forwarding


How DS-TE Operates

Operations Performed by the Ingress LSR


Routing TableRouting Table

Extended IGPExtended IGP

Traffic EngineeringTraffic EngineeringDatabase (TED)Database (TED)

UserUserConstraintsConstraints

ConstrainedConstrainedShortest Path FirstShortest Path First

1) Store information from IGP flooding1) Store information from IGP flooding

3) Examine user defined constraints3) Examine user defined constraints

4) Calculate the physical path for the LSP4) Calculate the physical path for the LSP

5) Represent path as an explicit route5) Represent path as an explicit route

2) Store traffic engineering information2) Store traffic engineering information Explicit RouteExplicit Route

RSVP SignalingRSVP Signaling


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

LSR1 LSR2 LSR3 LSR4 LSR5

Primary

Primary

Primary

Primary

Detour Detour Detour

Single user commandat head end to enable

Fast Reroute.

• 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

050

100

150200

250300350

400

5.0 5.1 5.2 5.3+

JUNOS version

MaxAverageMin

MS

econ

ds

MS

econ

ds


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

juniper networks presentation template-emea

Documents