Embed
Email

QoS

Document Sample
QoS
Shared by: HC11112509757
Categories
Tags
Stats
views:
5
posted:
11/25/2011
language:
English
pages:
88
QoS





Chapter 8

Introduction



 QoS is one of the biggest issue

 A free service

 Paying subscribers

 Service package

 Lower cost than the PSTN

 Voice and data service

 Technical solutions for providing QoS

 Various solutions

 Combined to complement each other







Internet Telephony 2

The Need for QoS

 A collective measure of the level of service

 For a particular application

 Performance criteria

 Availability, throughput, connection setup time,

percentage of successful transmissions, speed of fault

detection and correction

 Bandwidth, packet loss, delay and jitter

 IP is a best-effort service

 Well suited to non-real-time communication

 TCP

 Error-free, in-sequence delivery

 delay







Internet Telephony 3

 UDP

 Fine for transporting voice

 Provided that

 Low packet loss

 Little congestion on the network

 Traffic in the network can be bursty and unpredictable

 A speaker may be forced to repeat what he just said

 In case of significant packet loss



 To attract and retain paying subscribers

 Circuit switching has a distinct advantage

 But ill-suited to other forms of communication

 IP network: solutions for the QoS are needed

 Resource-reservation techniques

Internet Telephony 4

End-to-End QoS

 QoS must be end-to-end

 The support of all networks in the chain

 SLAs

 Service-Level Agreements between different

operators

 Regarding the type and quality of service to be

offered

 Or the penalties

 VoIP and voice over the Internet

 Are not the same

 SLAs may be possible between certain VoIP

carriers



Internet Telephony 5

 Things will get better

 VoIP for long-distance service

 Connected to the PSTN at each end

 Some VoIP operators

 Begin on IP and terminate on the PSTN

 More VoIP operators

 Over IP from source to destination

 All of the providers embrace the same quality objectives

and implement similar technical solutions

 Voice over the Internet?







Internet Telephony 6

It’s not just the network



 A quality service

 A lot more than just good voice quality

 A potentially high cost associated with acquiring a

customer

 Means

 Superior customer service, rapid service provisioning,

100 percent accurate billing, clear and concise product

descriptions, etc.









Internet Telephony 7

Overview of QoS Solutions



 One approach

 Reserve the resource before establishing the

session

 Has certain similarities to circuit switching

 Another approach

 Categorize traffic into different classes or priorities

 Real-time applications with higher-priority values

 Require a fair resource-allocation techniques

 The easiest technique

 The provision of more bandwidth





Internet Telephony 8

More Bandwidth



 Sounds like a simplistic and expensive

 No major system development

 Significant overbuild

 Unused for most of the time

 An inefficient way

 Huge advances in bandwidth

 9600-baud modem

 56kbps modem

 DSL

 The core of the network, DWDM





Internet Telephony 9

 Moore’s Law

 Doubles roughly every 18 months

 Bandwidth availability and bandwidth demand

have tended to move almost in lock-step

 New applications to use the available bandwidth









Internet Telephony 10

QoS Protocols and Architectures

 RSVP, Resource-Reservation Protocol

 RFC 2205

 Part of the IETF integrated-services suite

 Enable resources to be reserved for a given

session in prior

 The most complex, and closest to circuit emulation

 Strong QoS guarantees

 Significant granularity of resource allocation

 Significant feedback to applications

 Two levels of service

 Guaranteed - as close as possible to circuit emulation

 Controlled load – equivalent to the service in a best-

effort network under no-load conditions



Internet Telephony 11

 RSVP









Internet Telephony 12

 A sender issues a PATH message to the far end

 Contains a traffic specification (TSpec)

 Bandwidth requirement and packet size

 Each RSVP-enabled router along the way

 Establish a path state

 The previous source address

 The receiver of the Path message

 Responds with a Reservation Request (RESV)

 A flowspec: a TSpec and the type of reservation service

 The RESV message travels back to the sender

 Along the same route

 At each router, the requested resource is allocated

 Can accommodate multicast transport



Internet Telephony 13

 Differentiated Service, DiffServ

 A relatively simple means for prioritizing different

types of traffic

 RFC 2475

 Makes use of

 The IPv4 Type of Service (TOS) field

 The IPv6 Traffic Class field

 Known as the DS field

 Mark a given stream as requiring a particular type

of forwarding

 Per-Hop Behavior (PHB)

 Expedited Forwarding (EF)

 Assured Forwarding (AF)



Internet Telephony 14

 RFC 2598 specifies EF

 A given traffic stream is assigned a minimum departure

rate from a given node

 If the arrival rate r

 maximum packet size, M

 minimum policed unit, m

 All packets less than m bytes are considered to be m

bytes

Internet Telephony 23

 The overhead to process each packet

 Bound the bandwidth overhead of link-level headers

 The Token Bucket TSpec has parameter number

127









Internet Telephony 24

 Flowspec

 An indication of the QoS control service requested

 Controlled-load service and Guaranteed service

 For Controlled-load service

 Simply a Tspec

 For Guaranteed service

 A Rate (R) term, the bandwidth required

 R  r, extra bandwidth will reduce queuing delays

 A Slack (S) term

 The difference between the desired delay and the delay

that would be achieved if rate R were used

 Used to reduced the resource reserved







Internet Telephony 25

 Filter Spec

 An RSVP session

 A destination IP address and protocol ID

 An optional destination port number

 No information about the sender

 A problem to determine the specific data flow of a

reservation

 Define the flow to which a particular QoS is to be

applied

 A sender IP address and an sender port number (optional)

 For a video conference

 A different QoS requirement for each stream





Internet Telephony 26

 A router in the path must examine the header

 IP datagrams in the flow must not be fragmented

 Use path MTU discovery

 IP security might encrypt the header

 RSVP must include security functions

 IPv6 header is of variable length

 A greater processing effort

 Included in a PATH message

 A Sender template









Internet Telephony 27

 ADSpec

 PATH(TSpec)

 RESV(flowspec)

 The receiver to be informed about the network

 The receiver does not request what the network cannot

provide

 The sender and routers

 Indicate their QoS capabilities; advertising

 The sender constructs an initial ADSpec

 Each router update the ADSpec

 Also indicate that one or more routers RSVP-incapable







Internet Telephony 28

 Figure 8-9

 Service number 1

 X: a non-IS hop is involved in the path

 Not integrated Service capable – lacking RSVP support

 1, the rest of ADSpec is no longer relevant

 The number of hops between IS-capable nodes

 The path MTU

 The minimum path latency

 If no queuing delay









Internet Telephony 29

RSVP Messages



 Path (1), Resv (2), PathErr (3), ResvErr(4),

PathTear (5), ResvTear (6), RsevConf (7)

 A common header, Fig. 8-10

 Send_TTL = the IP TTL value of the message

 To determine that a non-RSVP hop has been involved

 IP TTL --, but not Send_TTL

 A number of objects

 Sender Tspec, ADSpec, etc.

 Class-num identifies the object itself

 C-Type identifies the different version

 e.g., IPv4 or IPv6



Internet Telephony 30

 SESSION Class

 Class-num = 1

 C-Type = 1, IPv4; 2, IPv6

 IP destination address, the protocol ID and (optional) the

destination port

 FLOWSPEC Class

 Class-num = 9

 C-Type = 2

 SENDER_TEMPLATE Class

 Class-num = 11

 C-type= 1, IPv4; 2, IPv6

 e.g., a filter spec in a Path message





Internet Telephony 31

 RSVP_HOP Class

 The IP address of the interface through which the last

RSVP-capable node passed this message

 Used in the Path message and saved at each node

 Ensure that the RESV message use the same path back

 Class-num = 3

 C-type= 1, IPv4; 2, IPv6

 TIME_VALUES Class

 A timeout period in milliseconds for the message

 Class-num = 5









Internet Telephony 32

 ERROR_SPEC Class

 In a RSVP error message

 the IP address of the node where the error was detected

 An error code plus additional cause information

 Class-num = 6

 C-type= 1, IPv4; 2, IPv6

 STYLE Class

 Select different reservation styles

 Multiple receivers and/or multiple senders

 Fixed-filter style: a receiver uniquely identifies a sender

 Wildcard-filter: for all data streams from all senders

 Shared-filter: lists specific senders

 Class-num = 8; C-type = 1





Internet Telephony 33

Example Reservations



 Successful reservation for a single sender and

receiver









Internet Telephony 34

Internet Telephony 35

 For a single sender and two receivers

 QoS requirement of Receiver 1 is stronger

 Receiver 2 requests a confirmation; Receiver 1

does not

 May lead to false confirmation

 e.g., the reservation request fails later









Internet Telephony 36

Internet Telephony 37

Reservation Errors



 A given resource reservation fails

 An error message is returned

 PathErr messages simply sent back to the

sender

 ResvErr messages are sent to a receiver

 Only to the receiver whose request fails









Internet Telephony 38

Guaranteed Service



 RFC 2212

 Two elements

 No packet loss

 Is a function of the token bucket depth (b) and the token

rate (R)

 Ensuring minimal delay

 A fixed delay due to processing

 The queuing delay > R

 If the node does not receive refreshing message

within L seconds

Internet Telephony 41

DiffServ



 RSVP

 The most comprehensive QoS mechanism

 Closest to circuit emulation

 RSVP-enabled routers maintain state

 Significant overhead and difficulty to scale up

 QoS in terms of bandwidth

 To increase the QoS is to increase the bandwidth

 RSVP reserve the resources

 DiffServ offers one application greater QoS at the

expense of another application

 If the second one will not notice a big difference





Internet Telephony 42

DiffServ Architecture



 IPv4 has a TOS field and IPv6 has a Traffic

Class field

 Diffserv renames the fields the DS field

 The least-significant six bits

 DSCP, DS Codepoint

 PHB, per hop behavior

 The packet is handled according to the DSCP

 RFC 2475

 An Architecture for Differentiated Services







Internet Telephony 43

 The packets of a given stream

 Marked with the appropriate DSCP value

 The routers provide the correct PHB

 The edge of the network ensures

 Only qualified packets are marked

 Metering to measure the packet rate

 The traffic meets an agreed-upon profile

 Traffic shaping and dropping

 These functions are called traffic conditioning







Internet Telephony 44

 Classifying and conditioning traffic









 The functions are pushed to the edge

 The changes in the core of the network is minimal

 Does not change with the number of applications

 Scales extremely well



Internet Telephony 45

The Need for SLAs



 A given network domain and packet source

must agree on

 Packet classification

 Traffic conditions

 The functions can be implemented

 At the source, or

 In an edge router

 SLAs between the customer and operator

 A definition of the traffic profile

 A token bucket specification





Internet Telephony 46

 The classification and marking rules

 Based on combinations of source address, destination

address, source port, destination port, protocol ID, time

of delay

 The behaviors for specific DSCP values

 Also specify for traffic outside the traffic profile

 Dropping of packets, the marking of non-conformant

packets, traffic shaping, additional charges

 SLAs between different network operators

 A common set of policies and PHB definitions

 The rules related to the service





Internet Telephony 47

Per-Hop Behaviors



 The treatment that a DS router applies to a

packet with a given DSCP value

 An aggregate

 The set of flows from one node to the next that

share the same DSCP codepoint

 PHB configuration is established w.r.t. aggregate,

rather than to specific flows

 Two PHBs are defined

 Expedited Forwarding

 Assured Forwarding





Internet Telephony 48

Expedited Forwarding



 EF PHB

 A service that is low loss, low delay; approximates

a virtual leased line

 By minimizing the queuing delay of each node

 The rate of departure of packets is a well-defined min

 And the arrival rate is always less

 The traffic-conditioning functions at the edge are

important

 The DSCP value is 101110









Internet Telephony 49

 The EF PHB implementations

 Unlimited preemption of other traffic

 Unacceptably low performance for non-EF traffic

 Does not inflict enormous damage to other traffic

 Using a token bucket limiter, or

 Weighted round-robin scheduler

 The share is equal to a configured rate

 The specific implementation can have an impact

on jitter

 Appendix of RFC 2598

 A comparison for a priority queue implementation versus

a weighted round-robin





Internet Telephony 50

 The Virtual Wire Behavior Aggregate

 An Internet draft

 Discusses the traffic conditioning for the EF PHB

 The aggregate should have a well-defined minimum

departure rate

 Strict shaping at the ingress to the DiffServ network can

ensure the traffic is carried jitter free

 As soon as the last bit of a packet is received, the router

starts send the packet

 The last bit of the next packet arrives before the last bit of

the first packet has departed

 No perceived jitter









Internet Telephony 51

Assured Forwarding



 The AF PHB

 RFC 2597

 High-priority packet are forwarded with a greater

reliability

 The traffic into a DiffServ network from a source

should conform a particular traffic profile

 Certain resources are allocated to certain behavior

aggregates

 Different levels of forwarding assurances









Internet Telephony 52

 Packets are marked with different AF classes

 Within each class, packets are marked with different

drop-precedence values

 If the resources allocated to a given class become

congested

 The router drops packets with higher drop-precedence

 Four classes and three drop-precedence levels









Internet Telephony 53

 The AF implementation

 Must detect and respond to long-term congestion

by dropping packets

 Respond to short-term congestion by queuing

 A function

 Monitors short-term congestion

 Derives a smoothed long-term congestion level

 Drop packets if necessary

 Must treat all packets within a given class and

precedence level equally

 All flows experience the same drop rate

 Must not reorder AF packets within a given AF class



Internet Telephony 54

Multi-Protocol Label Switching



 MPLS is not primarily a QoS solution

 A new switching architecture

 An IP router analyze the IP header to determine

the next hop

 The longest matched entry in the routing table

 MPLS attaches a label to the packet

 According to a FEC (Forwarding Equivalence Class)

 At the ingress to the network

 The label is examined in the next node and the

FEC is determined

 Via a simple table lookup

 A new label is attached, and the packet is forwarded



Internet Telephony 55

 The difference from the IP routing

 The FEC is determined at the point of ingress

 Where more information might be available

 e.g., QoS requirements

 A given FEC can force a packet to take a particular route

without having to cram a list of specific routers

 The label doest not necessarily imply a new

layer between layer 2 and 3

 The label can be carried at layer 2

 e.g., ATM VPI or VCI fields; Frame Relay DLCI

field





Internet Telephony 56

MPLS Architecture



 A Framework for Multiprotocol Label Switching

 An Internet Draft for the requirements

 Multiprotocol Label Switching Architecture

 An Internet Draft

 The ingress point: A packet -> an FEC -> a label

 At the next router: the label -> the FEC

 In addition, a table lookup -> the next hop and a new label

 The value of the label can be changed

 The FEC doe not change







Internet Telephony 57

 An example









Internet Telephony 58

 The relationship between the FEC and the label

value is a local affair

 Between two adjacent LSRs (Label-switching Routers)

 An upstream router must know the binding between

the label and FEC of the router downstream

 Packets with the same label from different routers

may have different FECs









Internet Telephony 59

 Label Assignment and Distribution

 Adjacent LSRs need to agree on label-to-FEC

bindings

 The downstream LSR decides on the particular

binding

 Then communicates the binding to the upstream LSR

 Through a label-distribution protocol

 RSVP has the extension

 LDP (Label-Distribution Protocol) has been developed

 Two ways

 Downstream-on-demand

 Unsolicited downstream





Internet Telephony 60

FEC and Labels



 An FEC can represent many things

 In reality

 The FEC takes the form of one or more IP

addresses or IP address prefixes

 LDP sepcifies

 An FEC is composed of a number of FEC elements

 Each element is either a host address or address

prefix

 Fig. 8-18







Internet Telephony 61

 A label can be an ATM VPI/VCI or a Frame

Relay DLCI

 Or, a shim layer between layer 2 and the

network layer

 32-bit label, shown in Fig. 8-19

 The label, 20 bits

 Time-to-live, 8 bits

 Experimental use, 3 bits

 S, 1 bit, indicates the label is the last in the stack







Internet Telephony 62

 ATM VPI/VCI, Fig. 8-20

 V-bits

 00: both VPI and VCI are significant

 01: only VPI

 10: only VCI

 Frame Relay, Fig. 8-21

 Len indicates the number of bits in the DLCI

 0: 10 bits long

 2: 23 bits long

 1,3: reserved









Internet Telephony 63

 The Label Stack

 A packet can have more than one label

 A label stack contains several labels

 An LSR bases its actions on the first (top) label

 Why might we need a label stack? Tunneling

 An tunneling example

 FEC F: LSP R1, R2, R3, and R4

 R2 and R3 are not directly connected

 Form a two ends of the tunnel R2, R2A, R2B, R2C and R3

 R2 replaces the first label and place a new label on top

 R2C recognizes it is the next-to-last LSR in the tunnel





Internet Telephony 64

 LSP tunnel









Internet Telephony 65

Actions at LSRs

 Depend on the value of the label

 The Next Hop-Level Forwarding Entry (NHLFE)

 Indicates the next hop, the operation to perform

on the label stack, and the encoding to be used

 e.g., replace the label at the top, pop the label

stack, or replace the top label, then add additional

labels on top

 The next hop might be the same LSR

 The LSR pop the top-level label and forwards the

packet to itself

 The packet might still have a label, or it might be

a native IP packet



Internet Telephony 66

 A given label might map to more than one

NHLFE

 For load sharing across multiple paths

 The LSR chooses one of the NHLFEs to use

 If a router knows it is the next-to-last LSR in

a given path

 It should remove any labels and pass the packet

to the final LSR without a label

 To minimize the amount of effort that the ultimate

LSR need to undertake

 Otherwise, the final LSR examines the label

 The next hop is itself, pop the stack and forward to itself





Internet Telephony 67

 How a particular LSR determines

 It is the next-to-last LSR for a given path

 A function of label distribution and the distribution

protocol used









Internet Telephony 68

Label-Switched Paths



 Label switching will be introduced

 In the form of islands within IP network

 There will be points of ingress and egress to the

MPLS network

 A point of ingress

 Choose the FEC for a given packet

 A point of egress

 Determine a label/FEC binding and passing that

information upstream







Internet Telephony 69

 An egress LSR w.r.t. a particular FEC

 If the FEC refers to the LSR,

 If the next hop for the FEC is outside of the MPLS

network, or

 If the next hop means traversing a boundary

 An LSP

 A path for a given FEC

 From an ingress LSR to the egress LSR

 Many points of ingress might exist

 The LSPs forms a tree with the egress LSR at the root

 LDP establishes and maintains the LSPs



Internet Telephony 70

MPLS Traffic Engineering



 One of the most important applications of

MPLS

 Modeling, characterization, and control of traffic to

meet specific performance objectives

 Might be traffic oriented or resource oriented

 The two objectives are not necessarily

mutually exclusive

 e.g., congestion avoidance is a common goal









Internet Telephony 71

 Congestion is primarily caused in two ways

 A lack of sufficient resources on the network

 Expand capacity

 Congestion-control techniques

 The steering to traffic towards loaded area

 Good traffic engineering

 OSPF (Open Shortest Path First)

 Tends to force traffic down the shortest route

 May promote congestion

 ATM: traffic engineering functions at layer 2

 Enable virtual circuits to be easily rerouted



Internet Telephony 72

Traffic Trunks



 A traffic trunk

 A set of flows that share specific attributes

 The ingress and egress LSRs, the FEC, and other

traffic characteristics

 Can explicitly specify the LSP that a traffic trunk

should use

 Steer traffic away from the shortest path

 Adapt to changing load conditions by changing the LSP









Internet Telephony 73

 Three main aspects of traffic engineering

 Mapping packets to FECs

 Mapping FECs to traffic trunks

 Mapping traffic trunks onto the physical network

topology through label-switched paths

 1st and 2nd are functions at the ingress

 3rd ensures that the network

 Provides the quality that is needed

 Can involve constraint-based routing

 Match the traffic and the available resources of the network







Internet Telephony 74

Constraint-Based Routing and LDP



 Constraint-Based LSP Setup Using LDP

 CR-LDP, an Internet draft

 Offers a routing capability

 The path is chosen according to certain

constraints

 Based on LDP

 LDP

 The establishment of LSPs with which particular

FECs are associated

 Discovery messages

 Announce and maintain the presence of an LSR



Internet Telephony 75

 Session messages

 Establish, maintain, and terminate sessions between LDP

peers

 Advertisement messages

 Create, change, and delete label mapping for FECs

 e.g., set up the actual LSPs

 Notification message

 Provide advisory information and signal error information









Internet Telephony 76

 The advertisement messages

 Label Request message

 An upstream LSR requests a downstream LSR to assign

and advertise a label for a given FEC

 Fig. 8-23

 Two optional parameters

 The Hop Count specifies the running total of the number of

LSR hops along the LSP

 Too many hops



 The Path Vector is a list of LSRs in the path

 For loop detection





 Label Mapping message

 Advertise a given label/FEC mapping

 Fig. 8-24

Internet Telephony 77

 CR-LDP enhances LDP

 Traffic parameters, resource requirements and

other characteristics can be incorporated in the

establishment of LSPs

 Enable the establishment of explicit routes

 A subset of constraint-based routes

 Explicit Routes

 A CR-LSP is an LSP that is established subject to a

number of criteria

 Based on information that is available at the edge of the

network







Internet Telephony 78

 An ER (Explicit Route) is one type of constraint-

based LSP where some or all of the nodes to be

used are specified

 A strict ER, all the nodes in the path are specified

 A loose ER, several nodes in the path are specified,

but other nodes can also be used

 CR-LDP enables explicit route information to be

included in the LDP Label Request message

 Define specific paths for traffic that has specific char









Internet Telephony 79

 Traffic Characteristics

 Be specified through the use of traffic parameter

 Fig. 8-25

 The peak rate: the Peak Data Rate and the Peak Burst

Size

 A token bucket specification

 The committed rate: the Committed Data Rate and the

Committed Burst Size

 The Excess Burst Size

 Used at the edge of the MPLS domain for traffic

conditioning

 The token bucket size is EBS and the token rate is CDR







Internet Telephony 80

 The Frequency

 How often the CDR should be made available

 1: average at least the CDR over any short interval (a

small number of the shortest packet times)

 2: Very frequent, average at least the CDR over any

packet interval

 The Weight determines

 The CR-LSP’s share of any possible excess bandwidth

above the committed rate









Internet Telephony 81

 Resource Classes

 To specify what links can be used in a given CR-LSP

 To limit the set of possible links

 Could indicate OC-48, ADSL, etc.

 Known as colors

 CR-LDP provides a means form indicating a resource

class in LDP messages

 Preemption

 If a CR-LSP cannot be established due to a lack of

available resources

 It is possible to reroute other traffic in order to make room

 The assignment of two priority levels to a given CR-LSP







Internet Telephony 82

 setupPriority

 The authority to preempt another

 hodlingPriority

 How much authority is required by another CR-LSP to

bump the CR-LSP

 The value 0 is most important, 7 the least

 For a given CR-LSP

 setupPriority <= holdingPriroity

 Modified LDP messages for CR-LDP

 The Label Request and Label Mapping messages are

modified

 Figs. 8-26 and 8-27

 The Pinning parameter is used with loose explicit routes





Internet Telephony 83

 Indicating whether or not a path can be changed at a

given LSR if a better next hop becomes available later

 The LSPID is a unique identifier for a CR-LSP

 End-to-End QoS

 How the traffic is classified and conditioned at the edge

of the MPLS network









Internet Telephony 84

Combining QOS Solutions



 The QoS solutions

 Each has its advantages and disadvantages

 RSVP

 Powerful

 Each router maintains path states

 DiffServ

 Simpler

 More of a prioritization techniques than a

resource-guarantee mechanism







Internet Telephony 85

 MPLS

 Great promise as an overall solution

 Significant changes to all routers

 Combining the solutions in smart ways

 Be used in different parts of the network

 e.g., RSVP in one domain and DiffServ in another

 Map an RSVP service request to an appropriate

DiffServ PHB

 Map a DiffServ behavior aggregate to an MPLS

FEC





Internet Telephony 86

 An example of combining QoS techniques









Internet Telephony 87

Further Information



 QoS is of major importance to the future of

IP networks

 Further Information

 IETF’s Web site

 QOS Forum

 Not a standards-setting body









Internet Telephony 88


Related docs
Other docs by HC11112509757
Harcourt Book 1-1
Views: 4  |  Downloads: 0
Weighted Least Squares example
Views: 10  |  Downloads: 0
Scans SimpleAnalyzer 10 06
Views: 0  |  Downloads: 0
INDICE
Views: 1  |  Downloads: 0
Sheet1
Views: 5  |  Downloads: 0
ENGLISH - CBSE
Views: 47  |  Downloads: 0
Rover Technology Infusion (incl CLARAty)
Views: 3  |  Downloads: 0
Contents Details
Views: 0  |  Downloads: 0
By registering with docstoc.com you agree to our
privacy policy

You are almost ready to download!

You are almost ready to download!