Other Application-Layer Profiles

BIG-IP^® Local Traffic Manager™offers several features that you can use to intelligently control your application layer traffic. These features are available through various configuration profiles.

A profile is a group of settings, with values, that correspond to a specific type of traffic, such as FTP traffic. A profile defines the way that you want the BIG-IP system to manage that traffic type. After you configure the type of profile you need, you assign it to a virtual server.

To manage application layer traffic, you can use any of these profile types:

• FTP (File Transfer Protocol)
• DNS (Domain Name System)
• RTSP (Real Time Streaming Protocol)
• ICAP (Internet Content Adaptation Protocol)
• Request Adapt and Response Adapt
• Diameter
• RADIUS (Remote Authentication Dial-In User Service)
• SIP (Session Initiation Protocol)
• SMTP
• SMTPS
• iSession
• Rewrite
• XML
• SPDY
• FIX
• video Quality of Experience (QOE)

In addition to these application layer profiles, Local Traffic Manager includes other features to help you manage your application traffic, such as health monitors for checking the health of an FTP service, and iRules^® for querying or manipulating header or content data. Additional profiles may be available with other modules.

HTTP compression reduces the amount of data to be transmitted, thereby significantly reducing bandwidth usage. All of the tasks needed to configure HTTP compression on the BIG-IP^® system, as well as the compression software itself, are centralized on the BIG-IP system. The tasks needed to configure HTTP compression for objects in an Application Acceleration Manager module policy node are available in the Application Acceleration Manager, but an HTTP compression profile must be enabled for them to function.

When configuring the BIG-IP system to compress data, you can:

• Configure the system to include or exclude certain types of data.
• Specify the levels of compression quality and speed that you want.

You can enable the HTTP compression option by setting the URI Compression or the Content Compression setting of the HTTP Compression profile to URI List or Content List, respectively. This causes the BIG-IP system to compress HTTP content for any responses in which the values that you specify in the URI List or Content List settings of an HTTP profile match the values of the Request-URI or Content-Type response headers.

Exclusion is useful because some URI or file types might already be compressed. Using CPU resources to compress already-compressed data is not recommended because the cost of compressing the data usually outweighs the benefits. Examples of regular expressions that you might want to specify for exclusion are .*\.pdf, .*\.gif, or .*\.html.

When used by BIG-IP^® Local Traffic Manager™ without other provisioned modules, the Web Acceleration profile uses basic default acceleration.

Local Traffic Manager™ includes a profile type that you can use to manage File Transfer Protocol (FTP) traffic. You can tailor FTP profile settings to your specific needs. For those settings that have default values, you can retain those default settings or modify them. You can modify any settings either when you create the profile, or at any time after you have created it.

You can create a custom DNS profile to enable various features such as converting IPv6-formatted addresses to IPv4 format, enabling DNS Express™, and enabling DNSSEC.

Local Traffic Manager^® includes a profile type that you can use to manage Real Time Streaming Protocol (RTSP) traffic. Real Time Streaming Protocol (RTSP) is a protocol used for streaming-media presentations. Using RTSP, a client system can control a remote streaming-media server and allow time-based access to files on a server.

The RTSP profile in Local Traffic Manager supports these features:

• The setup of streaming media over UDP. In this case, the control connection opens the required ports to allow data to flow through the BIG-IP^® system.
• Interleaved data over the control connection, essentially streaming media over TCP.
• Real Networks tunneling of RTSP over HTTP, through the RTSP port (554).

A common configuration for the RTSP profile is one that includes RTSP clients and media servers, as well as RTSP proxies to manage accounting and authentication tasks. In this proxied configuration, you most likely want the streaming media from the servers to pass directly to the client, bypassing the RTSP proxy servers.

To implement this configuration, you configure Local Traffic Manager by creating two virtual servers, one for processing traffic to and from the external network, and one for processing traffic to and from the internal network. For each virtual server, you assign a separate RTSP profile.

With this configuration:

• The RTSP profile on the external virtual server passes client IP address information to the RTSP profile on the internal virtual server.
• The RTSP profile on the internal virtual server extracts the client IP address information from the request, processes the media server’s response, and opens the specified ports on the BIG-IP system. Opening these ports allows the streaming media to bypass the RTSP proxy servers as the data travels from the server to the client.

The client IP address information is stored in the Proxy Header setting that you specify in the RTSP profile.

You can configure one or more Internet Content Adaptation Protocol (ICAP) profiles when you want to use the BIG-IP^® content adaptation feature for adapting HTTP requests and responses. This feature allows a BIG-IP virtual server to conditionally forward HTTP requests and HTTP responses to a pool of ICAP servers for modification, before sending a request to a web server or returning a response to the client system.

In a typical configuration, you create two ICAP profiles:

• You assign one of the profiles to a virtual server of type Internal that sends HTTP requests to a pool of ICAP servers.
• You assign the other profile to a virtual server of type Internal that sends HTTP responses to a pool of ICAP servers.

For more information on content adaptation for HTTP traffic, see the guide titled BIG-IP^® Local Traffic Manager: Implementations, available on the AskF5™ knowledge base at http://support.f5.com.

You can configure a Request Adapt or Response Adapt profile when you want to use the BIG-IP^® content adaptation feature for adapting HTTP requests and responses. A Request Adapt or Response Adapt profile instructs an HTTP virtual server to send a request or response to a named virtual server of type Internal, for possible modification by an Internet Content Adaptation Protocol (ICAP) server.

For more information on content adaptation for HTTP traffic, see the guide titled BIG-IP^® Local Traffic Manager: Implementations, available on the AskF5™ knowledge base at http://support.f5.com.

Local Traffic Manager™ includes a profile type that you can use to manage Diameter traffic. The Diameter protocol is an enhanced version of the Remote Authentication Dial-In User Service (RADIUS) protocol.

When you configure a Diameter type of profile, the BIG-IP^® system can send client-initiated Diameter messages to load balancing servers. The BIG-IP system can also ensure that those messages persist on the servers.

The BIG-IP^® system includes a profile type that you can use to load balance Remote Authentication Dial-In User Service (RADIUS) traffic.

When you configure a RADIUS type of profile, the BIG-IP system can send client-initiated RADIUS messages to load balancing servers. The BIG-IP system can also ensure that those messages are persisted on the servers.

Local Traffic Manager™ includes a services profile that you can use to manage Session Initiation Protocol (SIP) traffic. Session Initiation Protocol is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. A session can be a simple two-way telephone call or Instant Message dialogue, or a complex, collaborative, multi-media conference call that includes voice, data, and video.

SIP sessions, which are application level sessions, run through one of three Layer 4 protocols: SCTP, TCP, or UDP. The SIP profile configures how the system handles SIP sessions. The specified Layer 4 protocol profile configures the virtual server to open the required port to allow data to flow through the BIG-IP^® system. When you assign a SIP profile to a virtual server, you can also assign an SCTP, TCP, or UDP profile to the server. If you do not assign one of these protocol profiles to the server, Local Traffic Manager automatically assigns one for you.

The SIP profile automatically configures the BIG-IP system to handle persistence for SIP sessions using Call-ID. The Call-ID is a globally unique identifier that groups together a series of messages, which are sent between communicating applications. You can customize how the system handles persistence for SIP sessions.

You can create an SMTP profile to secure SMTP traffic coming into the BIG-IP system. When you create an SMTP profile, BIG-IP^® Protocol Security Manager™ provides several security checks for requests sent to a protected SMTP server:

• Verifies SMTP protocol compliance as defined in RFC 2821.
• Validates incoming mail using several criteria.
• Inspects email and attachments for viruses.
• Applies rate limits to the number of messages.
• Validates DNS SPF records.
• Prevents directory harvesting attacks.
• Disallows or allows some of the SMTP methods, such as VRFY, EXPN, and ETRN, that spam senders typically use to attack mail servers.
• Rejects the first message from a sender, because legitimate senders retry sending the message, and spam senders typically do not. This process is known as greylisting. The system does not reject subsequent messages from the same sender to the same recipient.

With an SMTP profile configured, the system either generates an alarm for, or blocks, any requests that trigger the security check.

The SMTPS profile provides a way to add SSL encryption to SMTP traffic quickly and easily. SMTPS is a method for securing Simple Mail Transport Protocol (SMTP) connections at the transport layer.

Normally, SMTP traffic between SMTP servers and clients is unencrypted. This creates a privacy issue because SMTP traffic often passes through routers that the servers and clients do not trust, resulting in a third party potentially changing the communications between the server and client. Also, two SMTP systems do not normally authenticate each other. A more secure SMTP server might only allow communications from other known SMTP systems, or the server might act differently with unknown systems.

To mitigate these problems, the BIG-IP system includes an SMTPS profile that you can configure. When you configure an SMTPS profile, you can activate support for the industry-standard STARTTLS extension to the SMTP protocol, by instructing the BIG-IP system to either allow, disallow, or require STARTTLS activation for SMTP traffic. The STARTTLS extension effectively upgrades a plain-text connection to an encrypted connection on the same port, instead of using a separate port for encrypted communication.

This illustration shows a basic configuration of a BIG-IP system that uses SMTPS to secure SMTP traffic between the BIG-IP system and an SMTP mail server.

Sample BIG-IP configuration for SMTP traffic with STARTTLS activation

The iSession™ profile tells the system how to optimize traffic. Symmetric optimization requires an iSession profile at both ends of the iSession connection. The system-supplied parent iSession profile isession, is appropriate for all application traffic, and other iSession profiles have been pre-configured for specific applications. The name of each pre-configured iSession profile indicates the application for which it was configured, such as isession-cifs.

When you configure the iSession local endpoint on the Quick Start screen, the system automatically associates the system-supplied iSession profile isession with the iSession listener isession-virtual it creates for inbound traffic.

You must associate an iSession profile with any virtual server you create for a custom optimized application for outbound traffic, and with any iSession listener you create for inbound traffic.

For environments that use web servers, you might want your websites to appear differently on the external network than on the internal network. For example, you might want the BIG-IP^® system to send traffic destined for www.company.com/usa/ to the internal server usa.company.com instead. Normally, this translation could cause some issues, such as the web server expecting to see a certain host name (such as for name-based virtual hosting) or the web server using the internal host name when sending a redirect to client systems.

You can solve these problems by configuring a Rewrite profile, which causes the BIG-IP system to act as a reverse proxy server. As a reverse proxy server, the BIG-IP system offloads the URI translation function from web servers enabled with features such as Apache's ProxyPass module. With a Rewrite profile, the BIG-IP system can perform URI scheme, host, port, and path modifications as HTTP traffic passes through the system. The feature also provides reverse translation for the Location, Content-Location, and URI headers in the server response to the client.

A typical use of a reverse proxy server is to grant Internet users access to application servers that are behind a firewall and therefore have private IP addresses and unregistered DNS entries.

You can use the BIG-IP^® system to perform XML content-based routing whereby the system routes requests to an appropriate pool, pool member, or virtual server based on specific content in an XML document. For example, if your company transfers information in XML format, you could use this feature to examine the XML content with the intent to route the information to the appropriate department.

You can configure content-based routing by creating an XML profile and associating it with a virtual server. In the XML profile, define the matching content to look for in the XML document. Next, specify how to route the traffic to a pool by writing simple iRules^®. When the system discovers a match, it triggers an iRule event, and then you can configure the system to route traffic to a virtual server, a pool, or a node.

The following example shows a simple XML document that the system could use to perform content-based routing. It includes an element called FinanceObject used in this implementation.

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:eai="http://192.168.149.250/eai_enu/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
   <soapenv:Header/>
   <soapenv:Body>
     <eai:SiebelEmployeeDelete
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
             <FinanceObject xsi:type="xsd:string">Route to Financing</FinanceObject>
             <SiebelMessage xsi:type="ns:ListOfEmployeeInterfaceTopElmt"
xmlns:ns="http://www.siebel.com/xml">
                   <ListOfEmployeeInterface xsi:type="ns:ListOfEmployeeInterface">
                         <SecretKey>123456789</SecretKey>
                                  <Employee>John</Employee>
                                  <Title>CEO</Title>
                   </ListOfEmployeeInterface>
             </SiebelMessage>
     </eai:SiebelEmployeeDelete>
   </soapenv:Body>
  </soapenv:Envelope> 
  

You can use the BIG-IP^® Local Traffic Manager™ SPDY (pronounced "speedy") profile to minimize latency of HTTP requests by multiplexing streams and compressing headers. When you assign a SPDY profile to an HTTP virtual server, the HTTP virtual server informs clients that a SPDY virtual server is available to respond to SPDY requests.

When a client sends an HTTP request, the HTTP virtual server manages the request as a standard HTTP request. It receives the request on port 80, and sends the request to the appropriate server. When the server provides a response, the BIG-IP system inserts an HTTP header into the response (to inform the client that a SPDY virtual server is available to handle SPDY requests), compresses and caches it, and sends the response to the client.

A client that is enabled to use the SPDY protocol sends a SPDY request to the BIG-IP system, the SPDY virtual server receives the request on port 443, converts the SPDY request into an HTTP request, and sends the request to the appropriate server. When the server provides a response, the BIG-IP system converts the HTTP response into a SPDY response, compresses and caches it, and sends the response to the client.

You can use the BIG-IP^® Local Traffic Manager™ SOCKS profile to configure the BIG-IP system to handle proxy requests and function as a gateway. By configuring browser traffic to use the proxy, you can control whether to allow or deny a requested connection. To implement the profile, you must associate it with a virtual server.

The BIG-IP^® system Local Traffic Manager™ (LTM^®) FIX profile provides you with the ability to use Financial Information eXchange (FIX) protocol messages in routing, load balancing, persisting, and logging connections. The BIG-IP system uses the FIX profile to examine the header, body, and footer of each FIX message, and then process each message according to the parameters that it contains.

The BIG-IP system supports FIX protocol versions 4.2, 4.4, and 5.0, and uses the key-value pair FIX message format.

The BIG-IP^® system's video Quality of Experience (QoE) profile enables you to assess an audience's video session or overall video experience, providing an indication of customer satisfaction. The QoE profile uses static information, such as bitrate and duration of a video, and video metadata, such as URL and content type, in monitoring video streaming. Additionally, the QoE profile monitors dynamic information, such as the variable video downloading rate. By measuring the video playing rate and downloading rate, the user experience can be assessed and defined in terms of a single mean opinion score (MOS) of the video session, and a level of customer satisfaction can be derived. QoE scores are logged in the ltm log file, located in /var/log, which you can evaluate as necessary.