Cisco Cisco Packet Data Gateway (PDG) Documentation Roadmaps

 

▄  Cisco ASR 5000 Series Product Overview 

This section provides an overview of the X-Header Insertion feature. 

Extension header (x-header) fields are the fields not defined in RFCs or standards but can be added to headers of 
protocol for specific purposes. The x-header mechanism allows additional entity-header fields to be defined without 
changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header 
fields should be ignored by the recipient and must be forwarded by transparent proxies. 

The X-Header Insertion feature enables inserting x-headers in HTTP/WSP GET and POST request packets. Operators 
wanting to insert x-headers in HTTP/WSP GET and POST request packets, can configure rules for it. The charging-
action associated with the rules will contain the list of x-headers to be inserted in the packets. 

For example, if an operator wants to insert header field x-rat-type in the HTTP header with its value being rat-type, i.e. 
the header inserted should be: 

x-rat-type: geran 

where, rat-type is geran for the current packet. 

Configuring the X-Header Insertion feature involves: 

Creating/configuring a ruledef to identify the HTTP/WSP packets in which the x-headers must be inserted. 

Creating/configuring a rulebase and configuring the charging-action, which will insert the x-header fields into the 
HTTP/WSP packets. 

Creating/configuring the x-header format. 

Configuring insertion of the x-header fields in the charging action. 

 

This section provides an overview of the X-Header Encryption feature. 

X-Header Encryption enhances the X-header Insertion feature to increase the number of fields that can be inserted, and 
also enables encrypting the fields before inserting them. 

If x-header insertion has already happened for an IP flow (because of any x-header format), and if the current charging-
action has the first-request-only flag set, x-header insertion will not happen for that format. If the first-request-only flag 
is not set in a charging-action, then for that x-header format, insertion will continue happening in any further suitable 
packets in that IP flow. 

Changes to x-header format configuration will not trigger re-encryption for existing calls. The changed configuration 
will however, be applicable for new calls. The changed configuration will also apply at the next re-encryption time to 
those existing calls for which re-encryption timeout is specified. If encryption is enabled for a parameter while data is 
flowing, since its encrypted value will not be available, insertion of that parameter will stop. 

  Recovery of flows is not supported for this feature. 

The following steps describe how X-Header Encryption works: 

X-header insertion, encryption, and the encryption certificate is configured in the CLI. 

When the call gets connected, and after each regeneration time, the encryption certificate is used to encrypt the strings.