1-nVLL is based on the definition of the classical point-to-point Virtual Leased Line (VLL) service, also known in literature as Premium service. The aim of the VLL service is to emulate a point to point connection at the IP layer. The requirements of VLL are the following:
- maximum one-way delay: during transmission over the leased line packets experience a delay time close to the sum of the transmission and propagation time, the two main delay components.
- average delay variation
- packet loss probability
- bandwidth
- MTU (?)
We call 1-nVLL branch each of the virtual leased lines the
1-nVLL service is composed of.
For each 1-nVLL branch, the VLL service metrics (maximum delay,
average delay variation, packet drop probability and bandwdith, ..)
have to be defined.
In addition, the definition of the identity of the n
1-nVLL branch end-points has to be defined.
One or more sites can make use of the 1-nVLL service at the same time.
In order to support the 1-nVLL service according to the aggregation scheme of diffserv all the eligible packets are marked at the border with a single DS codepoint and are treated in an aggregated fashion in the core.
The PHB selected for this type of service is the Expedited Forwarding (EF) codepoint (101110) or an equivalent one (e.g. precedence 101).
Edge router configuration
Classification and marking
For each 1-nVLL branch a traffic profile is defined for classification.
Marking is implemented such that eligibile packets matching at least
one of the traffic profiles (access-lists) are marked with DSCP 101110
if and only if according the traffic meter they are within the
contract.
Policing: for each edge router policing has to be enabled in each input interface in order to prevent EF traffic on each 1-nVLL branch from exceeding the maximum bandwidth guaranteed. The number of policing istances is equal to the number of 1-nVLL branches.
Traffic exceeding the policing rate are dropped.
The recommended tocken bucket parameters (e.g. normal and exceed burst size for policers based on the many-parameters token bucket algorithm, or the token bucket depth for two-parameters token bucket algorithm) will be defined according to experimental results.
Scheduling In the core the EF traffic load has to be estimated on each link and for each edge router and each egress interface involved in the 1-nVLL service, scheduling has to be enabled.
The EF queue service rate Rs has to be configured according to the estimated arrival rate Ra so that
Note: The EF standard recommends the deployment of small EF queues for delay and delay variation minimization (1 or more MTUs).
- bandwidth guarantees: 300 Kbps per destination
- marking:
- TCP traffic on a given range of port numbers marked with precedence 5 (1-nVLL traffic);
- best-effort: any UDP stream and TCP connections whose port number does not fit in the port range above.
- policing: deployed on the input interface of each edge router
- token bucket parameters:
- normal burst size: 8000 bytes
- exceed burst size: 16000 bytes (probably has to be set to 8000 by to reduce nput burstiness)
- policing rate: 300 Kbps, three policer instances for each edge router
- actions:
- conform: mark with precedence 5
- exceed: drop
- token bucket parameters:
- scheduling: deployed on each output ATM
connection (output direction) of each edge router.
- rate: depends on the aggregation degree in each direction. With symmetric routing on each ATM connection the mVLL bandwidth configured is the same at both ends
- queue depth: variable [1, 64] - to verify: is this variable important? it probably depends on EF traffic aggregation.
- ATM configuration: tx-ring-limit = 5 (parameter subject to tuning)
- Variables
- Parameters and test methdology
- Results
- A Two-bit Differentiated Services Architecture for the Internet; K.Nichols, V.jacobson, L.Zhang.
- QBONE Architecture v.1.0; Internet2 QoS Working Group