Jump to content

UPC and NPC

From Wikipedia, the free encyclopedia
(Redirected from Network Parameter Control)

Usage Parameter Control (UPC) and Network Parameter Control (NPC) are functions that may be performed in a computer network. UPC may be performed at the input to a network "to protect network resources from malicious as well as unintentional misbehaviour".[1] NPC is the same and done for the same reasons as UPC, but at the interface between two networks.

UPC and NPC may involve traffic shaping, where traffic is delayed until it conforms to the expected levels and timing, or traffic policing, where non-conforming traffic is either discarded immediately, or reduced in priority so that it may be discarded downstream in the network if it would cause or add to congestion.

Uses

[edit]

In ATM

[edit]

The actions for UPC and NPC in the ATM protocol are defined in ITU-T Recommendation I.371 Traffic control and congestion control in B ISDN [2] and the ATM Forum's User-Network Interface (UNI) Specification.[3] These provide a conformance definition, using a form of the leaky bucket algorithm called the Generic Cell Rate Algorithm (GCRA), which specifies how cells are checked for conformance with a cell rate, or its reciprocal emission interval, and jitter tolerance: either a Cell Delay Variation tolerance (CDVt) for testing conformance to the Peak Cell Rate (PCR) or a Burst Tolerance or Maximum Burst Size (MBS) for testing conformance to the Sustainable Cell Rate (SCR).

UPC and NPC define a Maximum Burst Size (MBS) parameter on the average or Sustained Cell Rate (SCR), and a Cell Delay Variation tolerance (CDVt) on the Peak Cell Rate (PCR) at which the bursts are transmitted. This MBS can be derived from or used to derive the maximum variation between the arrival time of traffic in the bursts from the time it would arrive at the SCR, i.e. a jitter about that SCR.[4]

UPC and NPC are normally performed on a per Virtual Channel (VC) or per Virtual Path (VP) basis, i.e. the intervals are measured between cells bearing the same virtual channel identifier (VCI) and or virtual path identifier (VPI). If the function is implemented at, e.g., a switch input, then because cells on the different VCs and VPs arrive sequentially, only a single implementation of the function is required. However, this single implementation must be able to access the parameters relating to a specific connection using the VCI and or VPI to address them. This is often done using Content-addressable memory (CAM), where the VCI and or VPI form the addressable content.

Cells that fail to conform, i.e. because they come too soon after the preceding cell on the channel or path because the average rate is too high or because the jitter exceeds the tolerance, may be dropped, i.e. discarded, or reduced in priority so that they may be discarded downstream if there is congestion.

The GCRA, while, possibly, complicated to describe and understand, can be implemented very simply. While it is more likely to be implemented in hardware, as an example, an assembly language implementation can be written in as few as 15 to 20 instructions with a longest execution path of as few as 8 to 12 instructions, depending on the language (availability of indirection and the orthogonality of the instruction set).

In AFDX

[edit]

Transmissions onto an Avionics Full-Duplex Switched Ethernet (AFDX) network are required to be limited to a Bandwidth Allocation Gap (BAG). Conformance to this BAG (and maximum transmission jitter) is then checked in the network switches in a similar way to UPC in ATM networks. However, the token bucket algorithm is recommended for AFDX, and a version that allows for variable length frames (one that counts bytes) is preferred over one that only counts frames and assumes that all frames are of the maximum permitted length.[5]

See also

[edit]

References

[edit]
  1. ^ ITU-T, Traffic control and congestion control in B ISDN, Recommendation I.371, International Telecommunication Union, 2004, page 6.
  2. ^ ITU-T, Traffic control and congestion control in B ISDN, Recommendation I.371, International Telecommunication Union, 2004, Annex A.
  3. ^ ATM Forum, The User Network Interface (UNI), v. 3.1, ISBN 0-13-393828-X, Prentice Hall PTR, 1995.
  4. ^ ITU-T, Traffic control and congestion control in B ISDN, Recommendation I.371, International Telecommunication Union, 2004, page 17
  5. ^ Aeronautical Radio, INC., Aircraft Data Network Part 7 Avionics Full Duplex Switched Ethernet (AFDX) Network, ARINC Specification 664P7.