Constraint-Based Unicast and Multicast: Practical Issues

flutteringevergreenΔίκτυα και Επικοινωνίες

29 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

86 εμφανίσεις

1

IMIC, 8/30/99

Constraint
-
Based Unicast and Multicast:

Practical Issues

Bala Rajagopalan

NEC C&C Research Labs

Princeton, NJ

braja@ccrl.nj.nec.com

2

IMIC, 8/30/99

What is Constraint
-
Based Routing?


Includes QoS
-
based routing and policy routing


New jargon to establish technical territory


Devised in the context of MPLS LSPs, but applies to microflows also
(generically, “flows”)

Flow with BW,
Delay, Loss &
Policy
Requirements

Link with bw, delay, loss
properties

Network with
bw, delay, loss
properties

Inter
-
domain
routing policies

Source

Dest

3

IMIC, 8/30/99

A Methodology for IP Network Design

Flow
Routing

Node
-
Pair Traffic
Demands & Initial
Topology

Link Capacity
Determination

Traffic Flow
on Links

Scheduling &
Buffering Scheme

Topology Optimization

Network Topology
& Routing



Constraint
-
based routing capability results in efficient design and resource utilization

4

IMIC, 8/30/99

Traffic Engineering and Constraint Based Routing


Current

TE

goal

is

to

map

traffic

onto

the

network

such

that

available

resources

are

utilized

efficiently

and

QoS

requirements

of

traffic

is

satisfied


MPLS

LSPs

are

envisioned

for

creating

virtual

trunks

that

carry

traffic

between

node

pairs

(equivalent

of

frame
-
relay

or

ATM

PVCs)
.

LSPs

isolate

resources

for

different

flow

aggregates

LSP 1

LSP 2

LSP 3

Microflows within an LSP

Routing constraints:



Resource requirement



Priority & Preemption



Policy



Resiliency requirement

Re
-
optimization of routing

5

IMIC, 8/30/99

Service Models (1) : VPN


Customer provides point
-
to
-
point demands and QoS requirements


Service provider capacity engineers and establishes virtual trunks (LSPs)

SP Network

Internet

Virtual Trunk

6

IMIC, 8/30/99

Service Model (2) : Diffserv


Service provider establishes SLAs with customers


SLAs indicate service quality based on traffic parameters


SLAs need not require customer specification of traffic matrix



Network design is difficult


SLA1

SLA2

SLA3

SLA4

SP1

SP2

source

dest

Traffic from source to dest must
receive treatment as per SLA1,
even though it goes through a
foreign SP. Also, dest may not be
known apriori.

7

IMIC, 8/30/99

Traffic Engineering for Diffserv


In principle:


Derive

point
-
to
-
point

demands

from

SLAs

and

traffic

measurements


Determine

virtual

trunking

requirements

between

node

pairs


Establish

trunks

using

CBR

dest

SLA1

SLA2

SLA3

SLA4

SP1

SP2

source

Virtual Trunks

8

IMIC, 8/30/99

Constraint
-
Based Routing Model in Summary


Given
:

Network

topology,

resource

availability,

policy

and

other

attributes

of

nodes

and

links


Flows
:

Aggregated

microflows

or

virtual

trunks


Dynamism
:

Keep

track

of

network

state

changes
;

dynamic

rerouting

of

flows

after

topological

changes
;

redundant

paths

and

load
-
balancing?


Routing

architecture
:

Distributed


Route

computation
:

Based

on

apriori

notions

of

optimization

of

resource

usage,

traffic

parameters,

routing

metrics,

etc
.


Route

computation

trigger
:

By

operator

using

offline

mechanisms


Route

maintenance
:

Based

on

specified

policies


Multicast
:

??


9

IMIC, 8/30/99

Practical Issues


Scalability
:

No

experience

with

large
-
scale

state
-
dependent

routing

in

the

Internet
;

current

proposals

limited

to

intradomain

flat

networks


Interdomain

Routing
:

State

transfer

between

domains

for

CBR?


Flexibility

in

Routing
:

CBR,

being

a

tool

for

optimization,

invites

proprietary

solutions
.

How

to

accommodate

a

plurality

of

solutions?


Multicast
:

What

is

the

model?



Static

trees,

computed

centrally


Dynamic

trees

on

a

per
-
group

basis?



Integration

within

a

service

management

framework
:

Defining

the

interfaces

to

capacity

management,

provisioning,

and

offline

network

analysis
.



10

IMIC, 8/30/99

CBR Approach 1: IGP Extensions (e.g., OSPF)


Add

CBR

features

to

existing

IGP

s
.
t
.

changes

are

minimal



Some

IGPs

provide

mechanisms

for

adding

new

messages,

e
.
g
.
,

OSPF

transparent

LSAs

Flood Resource LSAs

New route computation proc.

New update procedures

New resource tracking proc.

(only bw defined so far)

Existing DB representation

Only single area considered

Area 1

Area 2

11

IMIC, 8/30/99

CBR Approach 2: Proprietary Protocols


Proprietary message formats, update protocols, hierarchy arrangements, database
representation, etc.


Proprietary CBR features: Flow definition, priority, preemption, rerouting features, etc.


Requires homogeneous equipment

Proprietary Flooding

Area 1

Area 2

12

IMIC, 8/30/99

CBR Approach 3: Distributed Overlay


Utilize underlying IGP (DV or link state) for reachability computations


Efficient update propagation techniques for scalability (facilitates dynamic routing)


IGP
-
independent state representation


State aggregation for hierarchical routing possible


Metric values not constrained by IGP limitations


Requires only the definition of a standard interface between IGPs and CBR protocols, to be
implemented locally

CBR Protocol

CBR Database

Topology Mapping &
Interface Functions

Intra
-
domain LS Protocol

LS Database

To Peers

To Peers

13

IMIC, 8/30/99

CBR Overlay: Essential Ideas


CBR protocol utilizes underlying IGP for building an MST of the topology (MST based
on administrative link cost)


State information broadcast on the MST


State information synchronized and maintained as MST changes


Requires interface function to indicate topology change

Pt
-
to
-
Pt or broadcast link

Router

To nodes E
-
I

A

B

C

D

To nodes J
-
M

To nodes N
-
Q

To nodes R
-
W

A: Mcast updates from E
-
I, request sync.
B: Unicast updates from J
-
M
C: Unicast updates from N
-
Q

Network and MST

CBR sync. on a LAN

14

IMIC, 8/30/99

CBR Overlay on OSPF


Hierarchical

MST

construction
;

one

for

each

area

and

one

for

the

backbone


CBR

topology

database

generated

from

OSPF

database

using

interface

functions



Independent

representation

of

network

state,

including

summary

state

for

external

areas


Updates

sent

on

backbone

MST

are

propagated

on

area

MSTs

Area 1

Area 2

Backbone Area

Area 1

Area 2

Backbone Area

15

IMIC, 8/30/99

Route Computation