Difference between revisions of "Manual:Nv2"

From MikroTik Wiki
Jump to navigation Jump to search
Line 55: Line 55:


=== nv2-qos=frame-priority ===
=== nv2-qos=frame-priority ===
In this mode QoS queue is selected based on frame priority field. Note that frame priority field is not some field in headers and therefore it is valid only while packet is processed by given device. Frame priority field must be set either explicitly by firewall rules or implicitly by frame forwarding process, for example, from MPLS EXP bits. For more information on frame priority field see
In this mode QoS queue is selected based on frame priority field. Note that frame priority field is not some field in headers and therefore it is valid only while packet is processed by given device. Frame priority field must be set either explicitly by firewall rules or implicitly from ingress priority by frame forwarding process, for example, from MPLS EXP bits. For more information on frame priority field see:
*[[MPLS/EXP_bit_behaviour]]
*[[Manual:MPLS/EXP_bit_behaviour]]
*[[Manual:WMM]]
*[[Manual:WMM]]
Queue is selected based on frame priority according to 802.1D recommended user priority to traffic class mapping. Mapping depends on number of available queues (<b>nv2-queue-count</b> parameter). For example, if number of queues is 4, mapping is as follows (pay attention how this mapping resembles mapping used by WMM):
* priority 0,3 -> queue 0
* priority 1,2 -> queue 1
* priority 4,5 -> queue 2
* priority 6,7 -> queue 3
If number of queues is 2 (default), mapping is as follows:
* priority 0,1,2,3 -> queue 0
* priority 4,5,6,7 -> queue 1
If number of queues is 8 (maximum possible), mapping is as follows:
* priority 0 -> queue 2
* priority 1 -> queue 0
* priority 2 -> queue 1
* priority 3 -> queue 3
* priority 4 -> queue 4
* priority 5 -> queue 5
* priority 6 -> queue 6
* priority 7 -> queue 7
For other mappings, discussion on rationale for these mappings and recommended practices please see 802.1D-2004.

Revision as of 08:24, 29 September 2010

Overview of NV2 protocol

NV2 protocol is proprietary wireless protocol developed by MikroTik for use with Atheros 802.11 wireless chips. NV2 is based on TDMA (Time Division Multiple Access) media access technology instead of CSMA (Carrier Sense Multiple Access) media access technology used in regular 802.11 devices.

TDMA media access technology solves hidden node problem and improves media usage, thus improving throughput and latency, especially in PtMP networks.

NV2 is supported for Atheros 802.11n chips and legacy 802.11a/b/g chips starting from AR5212, but not supported on older AR5211 and AR5210 chips. This means that both - 11n and legacy devices can participate in the same network and it is not required to upgrade hardware to implement NV2 in network.

Media access in NV2 network is controlled by NV2 Access Point. NV2 AP divides time in fixed size "periods" which are dynamically divided in downlink (data sent from AP to clients) and uplink (data sent from clients to AP) portions, based on queue state on AP and clients. Uplink time is further divided between connected clients based on their requirements for bandwidth. At the begginning of each period AP broadcasts schedule that tells clients when they should transmit and the amount of time they can use.

In order to allow new clients to connect, NV2 AP periodically assigns uplink time for "unspecified" client - this time interval is then used by fresh client to initiate registration to AP. Then AP estimates propagation delay between AP and client and starts periodically scheduling uplink time for this client in order to complete registration and receive data from client.

NV2 implements dynamic rate selection on per-client basis and ARQ for data transmissions. This enables reliable communications across NV2 links.

For QoS NV2 implements variable number of priority queues with builtin default QoS scheduler that can be accompanied with fine grained QoS policy based on firewall rules or priority information propagated across network using VLAN priority or MPLS EXP bits.

NV2 protocol implementation status

As of version 5.0rc1 NV2 has the following features:

  • TDMA media access
  • WDS support
  • QoS support with variable number or priority queues

Features that NV2 DOES NOT HAVE YET:

  • data encryption
  • RADIUS authentication features
  • synchronization between NV2 APs
  • some other features...

Compatibility and coexistence with other wireless protocols

NV2 protocol is not compatible to or based on any other available wireless protocols or implementations, either TDMA based or any other kind, including Ubiquiti Airmax and FreeBSD TDMA implementation. This implies that only NV2 supporting and enabled devices can participate in NV2 network.

Regular 802.11 devices will not recognize and will not be able to connect to NV2 AP. RouterOS devices that have NV2 support (that is - have RouterOS version 5.0rc1 or higher) will see NV2 APs when issuing scan command, but will only connect to NV2 AP if properly configured.

As NV2 does not use CSMA technology it may disturb any other network in the same channel. In the same way other networks may disturb NV2 network, because every other signal is considered noise.

The key points regarding compatibility and coexistence:

  • only RouterOS devices will be able to participate in NV2 network
  • only RouterOS devices will see NV2 AP when scanning
  • NV2 network will disturb other networks in the same channel
  • NV2 network may be affected by any (NV2 or not) other networks in the same channel

How NV2 compares with Nstreme and 802.11

NV2 vs 802.11

NV2 vs Nstreme

Configuring NV2

Migrating to NV2

QoS in NV2 network

QoS in NV2 is implemented by means of variable number of priority queues. Queue is considered for transmission based on rule recommended by 802.1D-2004 - only if all higher priority queues are empty. In practice this means that at first all frames from queue with higher priority will be sent, and only then next queue is considered. Therefore QoS policy must be designed with care so that higher priority queues do not make lower priority queues starve.

QoS policy in NV2 network is controlled by AP, clients adapt policy from AP. On AP QoS policy is configured with nv2-queue-count and nv2-qos parameters. nv2-queue-count parameter specifies number of priority queues used. Mapping of packets to queues is controlled by nv2-qos parameter.

nv2-qos=default

In this mode outgoing frame at first is inspected by built-in QoS policy algorithm that selects queue based on packet type and size. If built-in rules do not match, queue is selected based on frame priority field, as in nv2-qos=frame-priority mode.

nv2-qos=frame-priority

In this mode QoS queue is selected based on frame priority field. Note that frame priority field is not some field in headers and therefore it is valid only while packet is processed by given device. Frame priority field must be set either explicitly by firewall rules or implicitly from ingress priority by frame forwarding process, for example, from MPLS EXP bits. For more information on frame priority field see:

Queue is selected based on frame priority according to 802.1D recommended user priority to traffic class mapping. Mapping depends on number of available queues (nv2-queue-count parameter). For example, if number of queues is 4, mapping is as follows (pay attention how this mapping resembles mapping used by WMM):

  • priority 0,3 -> queue 0
  • priority 1,2 -> queue 1
  • priority 4,5 -> queue 2
  • priority 6,7 -> queue 3

If number of queues is 2 (default), mapping is as follows:

  • priority 0,1,2,3 -> queue 0
  • priority 4,5,6,7 -> queue 1

If number of queues is 8 (maximum possible), mapping is as follows:

  • priority 0 -> queue 2
  • priority 1 -> queue 0
  • priority 2 -> queue 1
  • priority 3 -> queue 3
  • priority 4 -> queue 4
  • priority 5 -> queue 5
  • priority 6 -> queue 6
  • priority 7 -> queue 7

For other mappings, discussion on rationale for these mappings and recommended practices please see 802.1D-2004.