70 -- HARDWARE OR SOFTWARE THAT WILL MONITOR AND DISPLAY NETWORK INCIDENTS

Notice Date

June 25, 2001

Contracting Office

CECOM Acquisition Center Southwest Operations Office, Attn: AMSEL-AC-CC-E-CB, Building 61801, Room 3210, Fort Huachuca, AZ 85613-6000

ZIP Code

85613-6000

Solicitation Number

N/A

Response Due

July 6, 2001

Point of Contact

Dr. Lee Spencer, US Army Network Engineering and Telecommunications Activity , DSED, Phone:520-538-6864, FAX: 520-538-7059

E-Mail Address

Point of Contact (lee.spencer@hqasc.army.mil)

Description

Quality of Service over Internet Protocol (IP) Networks DOD has established a technical working group named the Global Information Grid (GIG) Quality of Service (QoS) working group (GQWG). Their goal is to define the appropriate values for selected performance metrics. These metrics will be collected for each type of application flow in the DOD's global network. The definitions of the application flows we are using are given in attachment (1). The performance metrics being considered are given in attachment (2). We are requesting vendor input regarding performance requirements for their specific products, whether hardware or software, with the goal of populating all or part of the matrix in attachment (3). The results of the GQWG will guide DOD in future implementations. Input received before 6 July 2001 will be most useful for our consideration. POC: Dr. Lee Spencer US Army Network Engineering and Telecommunications Activity , DSED e-mail: lee.spencer@hqasc.army.mil Phone:520-538-6864 Pager: 800-950-4512 FAX: 520-538-7059 1. Attachment 1 IP Network Application Flow Definitions Definition of Continuous/Interactive Flow (Developed by Applications IPT) Continuous/Interactive information flow is any uninterrupted, real-time, two-way data communication. Prime examples of this would be Voice over IP and VTC, which require high network availability and quality in order to be effective. These applications are characterized by their sensitivity to latency and jitter. Volume of data may vary widely. Definition of Block Transfer Flow (Y.800 Amended) As a response to a "click" on a home page at a terminal computer, for example, a data block that contains information data and a program file, such as a JAVA Applet for full motion video, is sent all at once. An application data unit (ADU) is sent by several IP packets. Block transfer delay is the main concern from the QoS and middleware performance viewpoint. Block transfer flow requires reliable and timely service delivery. Definition of Streaming Flow (Y.800 Amended) Audio and video communications require end-to-end bandwidth in the network (these bandwidths are related to the communications quality). This type of traffic is characterized as a continuous data-transmission stream. In multicasting, stream data traffic may be sent simultaneously from one site to many destinations. ADUs are generated more-or-less constantly. Maintaining the end-to-end bandwidth is the main concern. Timely service delivery is a characteristic of streaming flow. Definition of Transaction Flow (Y.800 Amended) Transaction type of communication, such as that used for electronic commerce, electronic banking, electronic ordering, etc. generates bi-directional data transmission with small-sized data packets (a few kilobits), and requires low data transmission latency in the network. An ADU is sent in a single packet. Packet latency is the main concern. In addition to being conversational, transaction flow exhibits timely and reliable service delivery. Definition of Best Effort Flow (Y.800 Amended) As with the Internet, an ADU is sent without any guarantee of QoS. For example, TFTP is a non-interactive application and may reach the destination in a few seconds or in a few minutes. Best effort service describes the least demanding flow-type. It makes no demands on reliability or timeliness: nor is it conversational. Examples of applications requiring best effort flow are TFTP, SNMP, DHCP, ICMP, and many routing protocols. Definition of Batch Transfer Flow (Developed by Applications IPT) Batch transfer flow is a one-way data communication which is not time sensitive and often is processed and transferred as a background process or at off peak times. Prime examples of this would be e-mail and FTP file transfers. While not time sensitive, batch transfer flow features reliable data transfer. 2. Attachment 2 IP Network Performance Parameters Latency or One-way IP packet transfer delay -- using an upper bound on "estimated" mean. (ITU-T Y.1540) Jitter or One way IP packet transfer delay variation -- using the difference (IPTDmax-IPTDmin) during the measurement interval. The 95th percentile of these values is expected to meet the applications transport network objective. (ITU-T Y.1540) One way IP packet loss ratio -- expressed as a % of total packets lost/total packets sent. (ITU-T Y.1540) Throughput (ITU-T Y.1540) The total number of octets transmitted in IP packets that were successfully transmitted during a specified time interval divided by the time interval duration Availability (ITU-T Y.1540) IP Service Availability 100 Percent IP Service Unavailabililty (PIU) PIU The percentage of total scheduled IP service time that is categorized as unavailable using the IP service availability function IP Service Availability Function: IPLR > C1 IP packet severely loss ratio (ITU-T Study Group 13 D.958) The percentage of total scheduled IP service time that is categorized as severely loss state using the IP service severely loss judgment function to total scheduled IP service time that is categorized as available using the IP service available function IP service severely loss judgment function: C2<IPLR<C1; C1 0.75, C2 0.2 3. Attachment 3 Contact Dr. Lee Spencer for the Matrix.

Record

Loren Data Corp. 20010627/70SOL008.HTM (W-176 SN50P9I0)