Starent Chicago Ad Hoc

8/4/2019 Starent Chicago Ad Hoc

http://slidepdf.com/reader/full/starent-chicago-ad-hoc 1/35

EV-DO Rev A End to End QoS

Dave Dukinfield

Sr. Network Consultant

August 2007



Starent Networks Proprietary and Confidential 2

End-to-End view of EVDO-Rev-A MFPA and QoS

GPP3 3

Protocols

Mobi leStation

BSC /PC F PD SNFar-EndTerminal

Applica tion QoS N egotia tio n (e .g . SIP /S D P)

IP QoS

Radio QoS

Signaling

IP N etwork

App. Qo S

GPP3 3

Protocols

Packet Data Qo S Signaling (R SVP- like

messages)

A /A QoS3 3 3

Signaling




PCF-to-PDSN InterfaceChanges

AAA Server

A33

PDSN

Main A11

Auxiliary

A s33

RAN/PCF

IP Flows

Link Flows

IP Network

end-to-end IP Flows

MS/ATMS/AT




RSVP TFT

Internet

PDSN

AAA

P-CSCF

Fwd RLP Flow # 0 (BE)

Rev RLP Flow # 0 (BE)

Fwd RLP Flow # 1

Rev RLP Flow # 1

Request QoS

for the bearer RP Signaling I/S-CSCF

Profile Mgr Profile ID1=VoIP

EV-DO Rev A ServiceMultiflow QoS

• PDSN uses RSVP TFT signaling for flow mapping & packet filter establishment – A single A11 can signal up to 7 bidirectional auxiliary service connections per session

& up to 10 service flows – May include optional channel treatments (ROHC or VJ header compression)

• Benefits: Enables provisioning of QoS differentiated convergedservices – Permits real-time, delay sensitive services with acceptable call quality on MMD

networks




A11 Requests

• A10 connection created by A11 request from PCF

• A11 includes: – Data service option type - represented standard SO codes

– SR_ID 1 (Main A10)

– Default flow IDs - 255 forward, 255 reverse

• When PDSN receives A11 request: – PDSN authenticates and retrieves the QoS from AAA

– PDSN sends back A11 RRP to establish MAIN A10




Rev A Call Setup

MS becomes aware

of a dataflow thatrequires a specific

QoS

3

3

MN RAN AAAPDSN

3

3

3

3

3

11

33

33

3

3

1. A11 RRQ (establish Main 10)2. Access Request (PDSN request subscriber QoS

profiles)

3. Access Accept (QoS profiles received)

(MS becomes aware of a dataflow that requires a

specific QoS)

4. Main A10 establishment:

a) PDSN sends RRP

b) PPP/LCP/IPCP negotiates

c) PDSN sends A11 Session Update

d) PCF sends A11 Update Ack to PDSN

5. RSVP (MN requests flow with a particular QoS)

6. RAN authorizes access and QoS

7. RAN sends QoS confirmation

8. MN acknowledges confirmation

9. A11 RRQ (establish Aux A10's)

10. A11 RRP (establish aux A10s)

11. MN sends TFT to PDSN

12. PDSN confirms receipt of TFT


http://slidepdf.com/reader/full/starent-chicago-ad-hoc 7/35Starent Networks Proprietary and Confidential 7

QoS on the PDSN

• QoS on the PDSN consist of two things: – Rev A QoS Profiles—Subscriber based profiles configured on the AAA

server, which are defined by the provider.

– Policies—Configured in a Policy Lookup Table on the PDSN using ITC.

PDSN validates the Policies after the Auxiliary A10s are setup over the PCF-PDSN to determine what type of flow treatment (if any) toapply to the application flows sent from the MN.



Intelligent Traffic ControlDifferentiated QoS / DoS Support

• Goals: Facilitate migration of subscribers to Rev A network – Enable Differentiated QoS End to End

– Define multiple high priority, low latency QoS levels to provide rapid set-uprequired of Multimedia based services

• ITC policy engine requirements – 5 tuple packet filters – static or dynamic policy definitions

– Apply DSCP marking from user payload to reverse tunneled MIP headers

– Apply DSCP in forward direction to A10 GRE header per Policy-Map

– Apply DoS eligibility bit to A10 GRE header in forward direction



• ITC is a licensed feature

• Uses flow-based traffic policing

• Enables configuring and enforcing bandwidth limitations per

subscriber for both uplink and downlink directions

• Supports various policy definitions for:

• QOS

• Bandwidth

• Access Control

• Policy definitions enforce and manage service level

agreements per subscriber profile

Differentiated QoS / DoSSupport



The Subscriber QoS Profile

• QoS Authorization is based on the per subscriber QoSprofile that is stored in the Home AAA

• The PDSN downloads the profile during PPP/MIP setup andstores the info. The PDSN also forwards the relevant info tothe RNC

• The Sub QoS profile consists of the following : – The Maximum Authorized Aggregate Bandwidth for Best-Effort traffic

– The Authorized QoS Profile IDs for each direction

– The maximum per Flow priority

– Inter-User Priority for best effort traffic

– Service Option profile

– The Allowed Number of Persistent TFTs

– The Allowed Differentiated Services Markings

• If MN performs no PPP/MIP auth, then the PDSN uses a

default QoS profile that is locally provisioned




Traffic Control Templates (TFT)

• Traffic flow templates are sent from the MN after Main and Aux. A10’s are created

• TFT contains: – One or more packet filters

– Source and destination ports

– Source and destination addresses

– Protocol

• TFT are sent to PDSN via RSVP




Dynamic Flow Mapping

• The protocol used for flow mapping: – The protocol used is RSVP (RFC 2205) with some protocol

exceptions.

– The RESV message is sent directly to the PDSN w/o a PATHmessage.

– The RESV message is destined for the PDSN and not to any end-host. The Protocol ID is set to 17 and DstPort is set to 3455.

– The RESV message contains a 3GPP2_Object. The 3GPP2_Objectwas created to carry the TFT (Traffic Flow Template) for flowmapping, HRIP (Header Removal Initialization Parameters, 1x only)and Channel Treatment Info.

– The 3GPP2_Object has the following IANA assignment: Class Number = 231, Class Name = 3GPP2_OBJECT Class Type or C-Type = 1.




Sample TFT

<srid value="4" so="64" />

<flow_discriminator value="1" />

<specific value="false"/>

<flow_dir value = "forward" />

<opcode value="add_pkt_fltr" />

<pkt_fltr flow_id="155" >

<precedence value="127" />

<dscp value="3e"/>

<req_prof_ids value="67,1915,864,1655,12127" />

<pkt_fltr_content pf_type="0">

<pkt_fltr_component type="">

<port_src_start value="15000" />

</pkt_fltr_component>

<pkt_fltr_component type="">

<port_src_end value="15999" />

</pkt_fltr_component>

</pkt_fltr_content>

</pkt_fltr>




Overview of QoS Signaling

•The HAAA sends the Authorized QoS Profile Ids, Service Option Profileto the PDSN during the PPP/Mobile IP session setup

• The PDSN sends the Authorized QoS Profile Ids, Service OptionProfile to the RAN/RNC via IOS signaling at the time of the packet datasession establishment (simple/mobile IP) and may update the QoSprofile later if necessary

• The QoS_BLOB is exchanged between the MS and the RAN/RNC viaover the air signaling

• Establish service instances/RLP flows via over the Air signaling

• The RAN/RNC performs QoS authorization and admission control and

sends the granted QoS to the MS• The RAN/RNC also sends the granted QoS to the PDSN for accounting

purpose via IOS Signaling

• RSVP-like messages exchanged between the MS and the PDSN for packet filter setup for flow mapping and flow based accounting




Rev A with Policy ValidationCall Setup

1. A11 RRQ (establish Main 10)

2. Access Request (PDSN request subscriber QoS profiles)


(MS becomes aware of a dataflow that requires a specific QoS)


a) PDSN sends RRP








9. A11 RRQ (establish Aux A10's)10.A11 RRP (establish Aux A10s)

11.MN sends TFT to PDSN

12.PDSN confirms receipt of TFT

13.PDSN Validates Policy by comparing info from TFT (step 11) and

PFC A11 (step 4).

14.Policy map is applied to flow and call is forwarded with proper flow

treatment

MS becomes aware

of a dataflow that

requires a specific

QoS

3

3

MN RAN AAAPDSN

3

3

3

3

3

11

33

33

3

3

33

33




Policy Validation Failure

1. A11 RRQ (establish Main 10)

2. Access Request (PDSN request subscriber QoS profiles)


(MS becomes aware of a dataflow that requires a specific QoS)


a) PDSN sends RRP








9. A11 RRQ (establish Aux A10's)10. A11 RRP (establish Aux A10s)

11. MN sends TFT to PDSN

12. PDSN confirms receipt of TFT

13. Policy Validation Failure.

14. All flows are mapped over Main A10 with a flow treatment of Best

Effort

MS becomes awareof a dataflow thatrequires a specific

QoS

3

3

MN RAN AAAPDSN

3

3

3

3

3

11

33

33

3

3

33

(Main A , BE)33 33




Flow-based Traffic Policing

• Policy modules interact with the system through a set of welldefined entry points

• Provides access to a stream of system events

•Permit the defined policies to implement:

• Access Control decisions

• QOS decisions

• Accounting decisions

• Generally defined as:• Policy class map, policy map, and policy group

• Condition source/destination address or source/destination port etc.

• Action Flow classification, QOS processing, and DSCP marking




How Policy Validation Works

In making these determinations, the PDSN must use information from three sources:

1.TFT sent by the MN in step 11 (flow ID and filters).

2.A11 RRQ sent by the PCF in step 9 (QoS Profiles, SR_ID, and flow ID).

3.Policies configured with ITC (Profile ID and filters).

MN

Policy

class-map (name = TFT)

src-port range -33333333

polcy map (name = TFT)

class-map TFT

type dynamic three-gpp Rev-A prof ile -ID range x - x f low-ID any1 1111111111

policy group (PGroup- )3

policy map TFT

TFTSRC Port =3333

Filter ID = 3Qos Profiles

(from AAA)

PCFPDSN




How Policy Validation Works(continued)

MN

Policy

class-map (name = TFT)

src-port range -33333333

polcy map (name = TFT)

class-map TFT

type dynamic three-gpp Rev-A prof ile- ID range x - x f low- ID any1 1111111111

policy group (PGroup- )3

policy map TFT

TFTSRC Port =3333

Filter ID = 3Qos Profiles

(from AAA)

PCFPDSN

1. TFT is sent via RSVP message to be validated by the Policy group applied to the subscriber profile.

2. TFT is checked against class map found in the policy map defined in the policy group (PGroup1)

3. If TFT is matched successfully , the policy map is applied to the flow (no updates sent to PCF)

and the call is forwarded with the proper flow treatment.

If TFT is not matched successfully , the policy map cannot be applied to the flow (updates are sent to the PCF) and the call is

forwarded with a best effort across the Main A10 connection.




Differentiated QoS End to End QoS Overview Same DSCP marking through network

Main A10

Profile ID 261 SRID2

flow ID 1/2 FWD/REV

DSCP

0x2E

PCF PDSN/FA HA

BEBE

In-Net

Server

MIP Tunnel

0x2E 0x2E

Internet

BE




ITC Dynamic Policy for Differentiated QoS PDSN/FA- Forward Direction

PCF PDSN/FA HA

SRID 2; Flow ID 1 FWD (Profile ID 261) TFT a

1.Main A10 and Aux A10/Flows established,

TFT created on PDSN

SRID 2; Flow ID 2 REV (Profile ID 261) TFT b

SRID 2; Flow ID 1 FWD (Profile ID 261)

Policy-261-out marked DSCP 0x2E /DOS

Main A10 0xBE

Traffic matched TFT a

MIP Tunnel

Traffic matched TFT c

BE Traffic

2. Upon successful session/flows setup, dynamic policy

facility in ITC can be used to provide the QoS treatment

(such as DSCP marking & DOS) by matching the TFT

dynamically established with the flows. Based on the different

flow criteria (profile ID & TFT), different dynamic policy will

get applied to the flows–

Class-Map class261-out (matching TFT a)

….

Policy-Map policy-261-out

class-map class261-out

3gpp2 data-over-signaling marking

qos encaps-header dscp 0x2E

Policy-Group Differentiated QoS_policy

policy-261-out precedence 1

….




ITC Dynamic Policy for Differentiated QoS PDSN/FA- Reverse Direction

PCF PDSN/FA HA

SRID 2; Flow ID 1 FWD (Profile ID 261) TFT a

1.Main A10 and Aux A10/Flows established,

TFT created on PDSN

2. Upon successful session/flows setup, dynamic

policy facility in ITC can be used to provide the QoStreatment (such as DSCP marking) by matching the

TFT dynamically established with the flows. Based on

the different flow criteria (profile ID & TFT), different

dynamic policy will get applied to the flows –

Class-Map class261-in (matching TFT b)

….

Policy-Map policy-261-in 0x2E

….

Policy-Group Differentiated QoS_policypolicy-261-in precedence 3

….

SRID 2; Flow ID 2 REV (Profile ID 261) TFT b

SRID 2; Flow ID 1 FWD (Profile ID 261)

PCF marked DSCP 0x2E

Main A10 0xBE

Traffic matched TFT b

Policy-261-in marked MIP tunnel header 0x2E

MIP Tunnel

BE Traffic




ITC Static Policy for Differentiated QoS HA- Forward Direction

PDSN/FA

HAHA could use static policy facility in ITC to provide thesession QoS service such as DSCP marking. The

subscriber traffic will be matched using the pre-defined

filters in the classmap –

Class-Map class-261-out src_port 2000

…

Policy-Map policy-261-out (static) 0x2E

….


policy-261-out precedence 1

src_port 2000 match policy-261-out

HA marked DSCP 0x2E

MIP Tunnel

0xBE

network

src_port 2000

Server marked DSCP 0x2E

QoS

required

Service

0xBE




ITC Static Policy for Differentiated QoSHA- Reverse Direction

PCF PDSN/FAHA

HA could use static policy facility in ITC to

provide the session QoS service such as DSCPmarking. The subscriber traffic will be matched

using the pre-defined filters in the classmap –

Class-Map class-261-in dst_port 2000

Policy-Map policy-261-in (static) 0x2E


policy-261-in precedence 3

dst_port 2000FA marked DSCP 0x2E

MIP Tunnel

0xBE

network

Policy-261-in matched dst_port 2000

HA marked DSCP 0x2E

0xBE

QoS

required

Service




1xEV-DO Rev A Multi-flow QoSAdditional Features

• QoS profile retrieval from H-AAA. Includes – Maximum Authorized Aggregate Bandwidth for Best-Effort traffic

– Authorized QoS Profile IDs for each direction

– Maximum per Flow priority

– Maximum inter-user priority

– Allowed Differentiated Services Markings

• Intra-chassis PDSN session recovery

• Flow-based accounting – Per-A10 accounting is the default system behavior

– Per-flow accounting or both per-flow and per-A10 accounting are possible

– MEID support in primary & auxiliary service connections

• Policy lookup table – L4 shallow packet inspection for initial TFT authorization & mid-session lookup

– Includes static traffic filters per application

– Per-flow traffic policing based on granted ProfileID

– Push-to-Talk (PTT) DSCP markings and DOS indication




Roaming Issues

• FlowProfileIDs – Roaming partners must agree upon which FlowProfileIDs will be

requested and supported

• Need to produce starter set (Voice, PTT, etc.) t of agreed uponstandard FlowProfileIDs

• DSCP markings – Need roaming partners agree upon markings

– CRX support of markings

• Subscriber-based QoS

– Prioritization of user profiles (home vs. roamers)




Thank You

For further information visit:

www.starentnetworks.com

Be advised that the information contained in Starent's product roadmaps do not constitute a promise or obligation of delivery of any functionality. Starent, at its sole

discretion, and without notice to Customer, reserves the right to alter the design, specifications, and forecasted time to market of all of its products on any roadmap, at any time, as part of its continuing program of product development.

This presentation is proprietary information of Starent Networks Corporation. The information contained may not be used to create or change any contractual obligation

between Starent Networks Corporation and you or your firm. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this

presentation by persons or entities other than the intended recipients is prohibited. This presentation is for planning and information purposes only. The specificationscontained herein are subject to change without notice.




Configuration

For further information visit:

www.starentnetworks.com

Be advised that the information contained in Starent's product roadmaps do not constitute a promise or obligation of delivery of any functionality. Starent, at its sole

discretion, and without notice to Customer, reserves the right to alter the design, specifications, and forecasted time to market of all of its products on any roadmap, at any time, as part of its continuing program of product development.

This presentation is proprietary information of Starent Networks Corporation. The information contained may not be used to create or change any contractual obligation

between Starent Networks Corporation and you or your firm. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this

presentation by persons or entities other than the intended recipients is prohibited. This presentation is for planning and information purposes only. The specificationscontained herein are subject to change without notice.




ST16/40 Rev-A Related Commandswhat’s new in the cli?

class-map name tft-voice match-any

match dst-port-range 2223 to 3333

policy-map name tft-voice

class-map tft-voice

type dynamic three-gpp2 rev-A profile-id range 0x100 to 0x110 flow-id any

access-control allow

qos encaps-header dscp-marking 0x2e

qos user-datagram dscp-marking 0x2e

policy-group name policyGroup-1

policy tft-voice precedence 3

subscriber default

authorized-flow-profile-id 256 direction bidirectional

policy-group policyGroup-1 direction in

policy-group policyGroup-1 direction out

show subscribers summary – verify summary rev-A flow and filter info

show subscribers all – verify access technology

show subscribers full – verify subscriber policy

show subscribers access-flows – verify summary of flow-mapping, Qos profile,

and flow-based policy info

show subscribers access-flows full - verify details of flow-mapping

show subscribers tft – verify details of installed traffic flow template info

Show rp full – verify Session Update Send Reason

show rp full all – verify GRE Key associated with A10 instance

monitor protocol A10, A11, User L3, (level 3 with hex and ascii) – verify signaland data between the PDSN and PCF, and between the PDSN and mobile

logging filter active facility sessmgr level debug – verify policy is applied, A10 is

added, flow is added, tft is validated, etc.

Show rsvp – verify RSVP related statistics/counters

Show subscriber access-tunnels – verify A10 connections at sessmgr level




Class Map

• Configured on a per-subscriber basis either locally on thesystem or on a remote RADIUS server

• Class Map:

• Match packet based on:

• Source/destination ip address

• IP TOS field

• Protocol

• Source/destination port number or range of port numbers

• Packet size

• Created in the egress context

• 32 Class Maps per egress context can be configured

• Set to match all or any of the classification rules




Class Map Example

class map name vpn-map match any

match src-port-range 1716

match dst-port-range 1716

match src-port-range 5001

match dst-port-range 5000

match src-ip-address 216.69.162.0/24

match dst-ip-address 216.69.162.0/24




Policy Map

• Policy Maps:• Access control (allow or discard)

• Qos traffic policing (cdr, pdr, cbs, with exceed and violate actions)

• Qos encapsulation header DSCP Marking (0x00 – 0x3f)

• Type (static or dynamic)

• Static type (the traffic flow classification and treatment is pre-

defined with classification rules in the class map)

• Dynamic type (is based on Rev. A flows)

• Class Maps are assigned to Policy Maps

• Created in the egress context

• 32 Policy Maps per egress context can be configured




Policy Map Example

policy-map name gold-vpnclass-map vpn-map

type static

access-control allow

qos traffic-police committed 0 peak 300000 burst-size112500

exceed-action lower-ip-precedence violate-action drop




Policy Group

• Policy Groups:• Direction (in or out)

• Precedence (if a session flow matches multiple policies this key word will

resolve them. A range from 1 to 16 can be assigned)

• Policy Maps are assigned to Policy Groups• Created in the egress context

• 16 Policy Maps per Policy Group can be configured



Policy Group Example

policy-group name goldpolicy gold-vpn precedence 2

policy gold-p2p precedence 3

Documents

Starent Chicago Ad Hoc