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.
Summary of Contents for ASR 5000 Series
Page 1: ......
Page 26: ......
Page 48: ...New In Release 10 0 SCM Features Cisco ASR 5000 Series Product Overview OL 22938 02 ...
Page 50: ......
Page 58: ......
Page 68: ......
Page 126: ......
Page 138: ......
Page 146: ......
Page 218: ......
Page 236: ......
Page 356: ......
Page 374: ......
Page 422: ......
Page 496: ......
Page 572: ......
Page 654: ......
Page 700: ......
Page 726: ......
Page 784: ......
Page 816: ......
Page 844: ......
Page 906: ......
Page 926: ......
Page 942: ......
Page 943: ...Cisco ASR 5000 Series Product Overview OL 22938 02 Chapter 30 Technical Specifications ...
Page 966: ......
Page 972: ......