The cumulative number of packets dropped because the packet would have triggered the creation of a new port map entry, but no port could be allocated for the protocol concerned. The usual case for this will be for a NAT instance that supports the 'Paired' pooling behavior recommended by RFC 4787, where the internal endpoint has used up all of the ports allocated to it for the address it was mapped to in this pool and cannot be given more ports because - policy or implementation prevents it from having a second address in the same pool, and - policy or unavailability prevents it from acquiring more ports at its originally assigned address. If the NAT instance pooling behavior is 'Arbitrary' (meaning that the NAT instance can allocate a new port mapping for the given internal endpoint on any address in the selected address pool and is not bound to what it has already mapped for that endpoint), then this counter is incremented when all ports for the protocol concerned over the whole of this address pool are already in use. This value MUST be monotone increasing in the periods between updates of the entity's natv2PoolDiscontinuityTime. If a manager detects a change in the latter since the last time it sampled this counter, it SHOULD NOT make use of the difference between the latest value of the counter and any value retrieved before the new value of natv2PoolDiscontinuityTime.