Cisco ASR 5000 Series, Обзор продукта

Страница: 746 / 992

Enhanced Charging Service Overview
▀ Enhanced Services in ECS
▄ Cisco ASR 5000 Series Product Overview
OL-22938-02
X-Header Insertion
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.
X-Header Encryption
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.
Important:
Recovery of flows is not supported for this feature.
The following steps describe how X-Header Encryption works:
Step 1
X-header insertion, encryption, and the encryption certificate is configured in the CLI.
Step 2
When the call gets connected, and after each regeneration time, the encryption certificate is used to encrypt the strings.