Bug #4836
closed
ns2: load sharing function for UDP data
Added by lynxis over 3 years ago.
Updated about 3 years ago.
Description
Implement the load sharing function for UDP data.
- on a new LSP select a NSVC based on data weight
e.g. count all weight as sum_weight, LSP %modulo sum_weight, select the NSVC.
NSVC1: data weight: 10
NSVC2: data weight: 5
sum = 15, LSP%sum in (0- 9) => NSVC1
sum = 15, LSP%sum in (10-14) => NSVC2
Maintain a LSP table per NSE containing "LSP, NSVC, timestamp/counter". The timestamp is used to remove old entries when the table is full.
- Description updated (diff)
- Category set to libosmogb
- Assignee set to lynxis
- Priority changed from Normal to High
Related: load sharing function for FR.
In the FR case, we should assume all weights are equal, and all NS-VC are equally suitable for signaling and user plane traffic.
In the TTCN3 code I chose to simply do a modulo operation of the identifier (LSP) into the array of currently unblocked NS-VCs. That of course means that every time links go up and down there will be a re-assignment of LSP to NS-VC. Some of hat would be avoidable in your list-based approach, but I would argue we can get away with the modulo-based approach. After all, when NS-VCs go down, we inevitably will have a re-distribution of traffic among the remaining NS-VCs. Your approach reduces the number of users/flows that gets redistributed. Not sure if it's worth the effort. The biggest danger in changing NS-VC for an established connection is re-ordering of a few messages.
- Status changed from New to In Progress
- % Done changed from 0 to 80
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Also available in: Atom
PDF
