Organizations

a portal for promoting internet and telecom
standardization knowledge

  RFC index search site map about tech-invite home
# IETF   # 3GPP   # ETSI
# Alliances, Fora, & other SDOs
Standardization work
# IETF WGs: RFCs & Drafts  
# IAB # IRTF
# 3GPP series   # ETSI committees
IETF topics
# SIP   # Security  
# Presence, IM & XCAP
# Conferencing   # Media Control  
# EAP   # Mobility Management  
3GPP topics
# Network Architecture   # GPRS  
# IMS   # Security Architecture  
# AKA   # GAA/GBA   # LI  
# GAN   # MBMS   # I-WLAN   # EPS  
# PCC   # Charging  
# HSS & Subscriber Data   # GUP  
# LCS   # Presence   # PoC  
# SIP-I   # ISC   # ICS  
ETSI topics
# TISPAN NGN  
Other topics
# M2M   # RFID   # NFC  
# Network Simulation
#public access
#private access (full or partial)
# public access so far, but very likely private access with next version
Prev Next   IPVCoSS - IP VPN CoS Simulator
##  Overview  ##  Single-Flow Examples  ##  Multiple-Flow Examples  ##  Throughput Calculation  ##  Scheduling 
##  TCP Congestion Control  ##  IP VPN Case Study  ##

IPVCoSS - IP VPN CoS Simulator
Overview

IPVCoSS (IP VPN CoS Simulator) is a stand-alone program that enables you to set up a network topology and inject traffic at ingress points. IPVCoSS is focused on IP data forwarding performance and assumes that data paths are pre-established. It can be configured to handle classes of service and to simulate one or more IP VPNs over a Service Provider backbone.

The network configuration is based on a data model and the data structures are built at initialization time. During its active phase, IPVCoSS runs a loop fictitiously cadenced at 100 nanoseconds (one tenth of microsecond) and at each tick, it analyses and ensures the progression of IP packets at each node and port. The transfer activity is triggered by the generation of IP flows, according to parameters such as volume, throughput and packet size. In output, IPVCoSS produces QoS final reports, QoS regular samples and, if required, a chronological trace of events.



The key elements of a network configuration are the ports. Ports are unidirectional and belong to a node. They are identified by a number, and their main attribute is the interface type, determining the rate. The 100-nanosecond clock accuracy enables IPVCoSS to process correctly IP interfaces ranging from E1 (2 Mbps) to STM-16 (2.5 Gbps). There is no explicit notion of links between nodes and the network topology is defined by the mapping between ports:
- An input port (IPORT) is a traffic ingress point at which a single IP flow, identified by a letter, is generated. An IPORT maps to an output port within the same node.
- An output port (OPORT) is an internal OPORT when it maps to one or more OPORTs in another node. The distance to this adjacent node is a key parameter of an internal OPORT.
- An output port is an egress OPORT when it does not map to another OPORT.

The conventional IP routing scheme is not used and paths are pre-determined by simple filtering, at OPORT level, based on flow identifiers. These paths represent MPLS label switched paths (LSP) in a core network.



For simplification and clarity, we have avoided having multiple logical interfaces per physical interface. ATM, Frame Relay and VLAN layer-2 framing is therefore not considered and the encapsulation type is automatically derived from the interface type:
- PPP HDLC framing for PDH and SDH interfaces: E1, E3, DS3 and STM-1, STM-4, STM-16.
- Ethernet (without VLAN) framing for Ethernet interfaces: FE, GE.

The two Figures below show respectively the framing structures with Ethernet and PPP. With Ethernet the overhead reaches 26 bytes, with a minimum interframe gap of 12 bytes. With PPP HDLC framing, the overhead is only 9 bytes, assuming a frame check sequence (FCS) field of 4 bytes, and there is no interframe gap.



The end-to-end chain of an IP packet from source to destination is shown in the Figure below. The equipment that host the IP source or destination are not modeled by IPVCoSS but they are supposed to be co-located respectively with the ingress IPORT and the egress OPORT, which are IPVCoSS reference end-points for an IP flow. At each OPORT along the flow path, and eventually at the egress OPORT, the delay, jitter and throughput QoS parameters related to any IP packet are measured, and can be compared to their initial value when generated at the ingress IPORT. These measurements are summarized in per-flow final reports.

When an IP packet (that includes the IP header) crosses a port, it is encapsulated in a frame that depends on the interface type. Besides, according to BGP/MPLS VPN architecture, one or two 4-byte MPLS shim headers may be inserted before the IP header, depending on the role of the service provider node.



Here are the attributes that define an IP flow. Some attributes characterize the IP flow and are permanent from end to end, while the other ones are used at generation time only.

Name Value Description
Identifier Single
printable
character		 Besides identifying the IP flow, this character is combined (in traces) with the packet serial number for identifying an IP packet. By convention, and although this is not a constraint, in a configuration using classes of services, the following ranges of letters will be used:
-A-Lfor BE flows
-M-Ufor AF flows
-V-Zfor EF flows
Class of
Service (CoS)		 Based on DiffServ "aggregate" terminology and assuming 3 physical queues per OPORT:
EF Expedited Forwarding:
low delay, low jitter, no loss, and highest priority (but not strict priority)
AF Assured Forwarding:
guaranteed rate while throughput respects the committed rate, but lower probability whenever excess traffic; this class enables several levels of service while preserving per-flow packet ordering (it is an Ordered Aggregate)
BE Best Effort:
the default class
Transport Protocol UDP UDP flows have no specific processing.
TCP TCP-based flows are responsive to traffic load and congestion. TCP congestion control mechanisms, normally handled at host system level, are simulated at ingress and egress ports level. IPVCoSS supports slow start and congestion avoidance mechanisms according to RFC 2581.
Packet Size 46-1500 bytes The packet size includes the IP header, and the allowed values are based on conventional Ethernet limits. This parameter specifies a fixed size for an isochronous flow, or a maximum size for a variable-rate flow.
Traffic Profile CBR Isochronous flow with fixed length packets generated at regular intervals, depending on the required throughput.
VBR Packets are generated at random with a variable size and at irregular intervals. The size varies between 46 bytes and the value specified in "packet size". There is also an option for having fixed size packets. The interval times are irregular but are constrained by the required throughput that is ensured, by adjustment, for each 3-full-sized-packet volume. With this profile, a SAVE / REPLAY option is offered for enabling the reproduction of the same variable flow from one run to another.
Throughput in Mbps The throughput determines the interval between packets. Depending on whether this interval value is rounded, or not, the throughput will be strictly respected or very closely approached.
Volume Number of
full-sized
packets		 For an isochronous traffic, IPVCoSS will generate the required number of packets while with a variable traffic, a larger number of packets will be effectively generated.
Number of Occurrences This optional attribute enables you to generate the required volume several times, with a fixed gap interval between two consecutive occurrences. This is useful for generating traffic bursts, instead of a continuous flow. The required throughput is ensured for each occurrence.
Gap Interval in milliseconds Time interval between two consecutive volumes of traffic.
Initial Tick in milliseconds Starting time for the generation of the first bit of the first packet of the IP flow.



Serialization delay samples

The delay experienced by an IP packet for a flow crossing a single node consists in the serialization delays at the ingress IPORT and egress OPORT as well as the processing delay (a fixed value configured at node level) and the queuing delay. The serialization time is dependent on the interface rate and the packet size, more exactly: the size of the packet's frame.



The table below mainly provides the serialization times in microseconds - with a precision of 100 nanoseconds - for some typical packet size values, according to PDH, SDH and Ethernet interface types. The real and useful rates are also provided for each interface type. As already mentioned, we do not consider multiple logical interfaces and assume a PPP encapsulation mode for PDH and SDH interfaces. For information, the maximum reachable IP throughput is shown, taking into account the frame overhead and the possible minimum gap interval between frames.

Interface
Type		 Physical
Rate
in b/s		 Useful
Rate
in b/s		 Packet
Length
in bytes		 Frame
Length
in bytes		 Packet
Length
in bits		 Serialization
Time
in microseconds		 Maximum IP
Throughput
in Mbit/s
E1 2,048 2,048 1,500 1,509 12,072 5894.6 2.04
1,000 1,009 8,072 3941.5 2.03
500 509 4,072 1988.3 2.01
46 55 440 214.9 1.71
E3 34,368 34,368 1,500 1,509 12,072 351.3 34.16
1,000 1,009 8,072 234.9 34.06
500 509 4,072 118.5 33.76
46 55 440 12.9 28.53
DS3 44,736 44,210 1,500 1,509 12,072 273.1 43.94
1,000 1,009 8,072 182.6 43.81
500 509 4,072 92.2 43.38
46 55 440 10.0 36.80
FE 100,000 100,000 1,500 1,526 12,208 122.1 97.48
1,000 1,026 8,208 82.1 96.27
500 526 4,208 42.1 92.81
46 72 576 5.8 54.12
STM-1 155,520 149,760 1,500 1,509 12,072 80.7 148.70
1,000 1,009 8,072 53.9 148.42
500 509 4,072 27.2 147.06
46 55 440 3.0 122.67
STM-4 622,080 599,040 1,500 1,509 12,072 20.2 594.06
1,000 1,009 8,072 13.5 592.59
500 509 4,072 6.8 588.24
46 55 440 0.8 460.00
GE 1000,000 1000,000 1,500 1,526 12,208 12.3 967.74
1,000 1,026 8,208 8.3 952.38
500 526 4,208 4.3 909.09
46 72 576 0.6 525.71
STM-16 2,488,320 2,396,160 1,500 1,509 12,072 5.1 2352.94
1,000 1,009 8,072 3.4 2352.94
500 509 4,072 1.7 2352.94
46 55 440 0.2 1840.00



Serialization delay samples

When an IP packet crosses 2 nodes, the serialization delay on the output port must not be accounted in input of the adjacent node. The distance of the link between the two nodes induces a propagation delay that is directly tied to the distance and is independent of both packet size and interface capacity. This delay cannot be avoided when the source and destination are located at far distant sites. It then depends on the topology of the SP network that might not be optimal with respect to these end points.



The table below provides propagation delay values according to several distances. The propagation delay is given by the formula:


  Distance in Kilometers   Distance in Miles   Propagation Delay  
1 km 5.6 µs
1 mile 9.0 µs
2 km 11.2 µs
3 km 16.8 µs
2 miles 18.0 µs
4 km 22.3 µs
3 miles 26.9 µs
5 km 27.9 µs
6 km 33.5 µs
4 miles 35.9 µs
7 km 39.0 µs
8 km 44.6 µs
5 miles 44.8 µs
9 km 50.2 µs
6 miles 53.8 µs
7 miles 62.8 µs
8 miles 71.7 µs
9 miles 80.7 µs
100 km 556.9 µs
100 miles 896.0 µs
200 km 1,113.7 µs
300 km 1,670.6 µs
200 miles 1,792.0 µs
400 km 2,227.4 µs
300 miles 2,688.0 µs
500 km 2,784.3 µs
600 km 3,341.1 µs
400 miles 3,583.9 µs
700 km 3,898.0 µs
800 km 4,454.8 µs
500 miles 4,479.9 µs
900 km 5,011.7 µs
600 miles 5,375.9 µs
1,000 km 5,568.5 µs
700 miles 6,271.8 µs
800 miles 7,167.8 µs
900 miles 8,063.8 µs
1,000 miles 8,959.7 µs
2,000 km 11,137.0 µs
3,000 km 16,705.5 µs
2,000 miles 17,919.4 µs
4,000 km 22,274.0 µs
3,000 miles 26,879.1 µs
5,000 km 27,842.5 µs
6,000 km 33,411.0 µs
4,000 miles 35,838.8 µs
7,000 km 38,979.5 µs
8,000 km 44,548.0 µs
5,000 miles 44,798.5 µs
9,000 km 50,116.5 µs
6,000 miles 53,758.2 µs
10,000 km 55,685.0 µs
7,000 miles 62,717.9 µs
8,000 miles 71,677.6 µs
9,000 miles 80,637.3 µs
10,000 miles 89,597.0 µs




IPVCoSS Trace example

Here is the trace of an IP Flow 'A' that is isochronous, at a rate of 20 Mbps and a packet size of 1500 bytes. This flow is generated at node CE1 on IPORT#1 and is sent on OPORT#51 towards node PE1. The E3 link that connects CE1 to PE1 is 40 km long and it induces a propagation delay of around 223 microseconds. There is no congestion and absolutely no jitter.




Here is a diagram that provides a visual perception of the occupancy of each port. As this can be seen in the trace here above, the serialization time of the 1500-byte IP packet in its Ethernet frame is 122.1 microseconds, while the same packet in its PPP frame on an E3 link is 351.3 microseconds, and only 80.7 microseconds on an STM-1 link.




Last update: November 18, 2009 
© 2005-2010 Joël Repiquet, All Rights Reserved.