A Session Initiation Protocol (SIP) Load-Control Event Package
Extracted elements (31)
Load filtering is proposed as a complementary mechanism to feedback-based SIP overload control. Feedback control is reactive and affects all calls equally; load filtering is proactive and most applicable when a traffic surge and its source/destination distribution can be predicted in advance, enabling targeted rate-limiting close to originating user agents.
The <many-tel> and <except-tel> sub-elements were introduced rather than reusing or redefining the "domain" attribute in RFC 4745's <many>/<except> elements, because adding attributes to those elements is not permitted and redefining "domain" would create backward-compatibility issues.
The <target-sip-entity> element exists to allow a load-filtering server with multiple routing paths to apply a received policy only to requests destined for the specific overloaded entity, avoiding unnecessary throttling of calls that can be routed through non-overloaded alternatives.
Before evaluating <call-identity> conditions, the subscriber shall convert URIs received in SIP header fields to canonical form per RFC 3261, except that the "phone-context" parameter of 'tel' URIs shall not be removed if present. Visual separators (e.g., "-") in 'tel' URIs are not used for URI comparison per RFC 3966.
Forking is not expected for this event package because subscriptions are addressed to clearly defined neighboring SIP entities. In the unlikely case forking does occur, only the first potential dialog-establishing message may create a dialog, per RFC 6665 Section 5.4.9.
When multiple rules in a ruleset define actions that match the same method, call identity, and validity period, a "first-match-wins" principle applies. Later rules matching the same request are not evaluated.
A notifier MUST send a NOTIFY request with its current load-filtering policy to the subscriber upon successfully accepting or refreshing a subscription. If no policy exists, the notifier SHOULD send a NOTIFY without a body, but the Content-Type header MUST still indicate the correct body format.
Any "drop" action applied to an unreliable transport (e.g., UDP) MUST be treated as if it were "reject", because dropping silently over UDP causes retransmissions that worsen overload.
For each NOTIFY transaction, a version number that increases by exactly one MUST be included in the NOTIFY request body when the body is present. Versions MUST be representable using a non-negative 32-bit integer. If a subscriber receives a NOTIFY with a version gap greater than one, it must resend a SUBSCRIBE to force a full state snapshot.
If the identity of the subscriber sending the SUBSCRIBE request is not allowed to receive load-filtering policies, the notifier MUST return a 403 "Forbidden" response.
In static load-filtering policy configuration, using the <rate> sub-element is RECOMMENDED over <percent> or <win> because it is hard to enforce percentage-rate or window-based filtering when incoming load from upstream or reactions from downstream are uncertain.
Non-initial requests such as ACK, BYE, and CANCEL MUST NOT be subjected to load filtering. Additionally, SUBSCRIBE requests are not filtered if the event-type header indicates the load-control event package itself.
Subscribers and notifiers are RECOMMENDED to explicitly negotiate appropriate subscription duration when knowledge about the mutual signaling relationship is available. The default expiration time is one hour.
This specification MUST be applied inside a Trust Domain — a set of SIP entities that agree on security mechanisms, membership determination, SIP compliance, RFC 6665 compliance, and compliance to this specification. Load filtering is only effective if all neighbors participate.
To avoid NOTIFY requests themselves overloading the system, it is RECOMMENDED that the notifier not generate notifications at a rate higher than once per second.
Upon receipt of a NOTIFY with Subscription-State "terminated", subscribers MUST also terminate previously received load-filtering policies from that notifier. The subscriber MUST discard unknown bodies.
When the "redirect" alt-action is used in an <accept> element, an "alt-target" attribute MUST be defined, specifying one URI or a list of URIs where the request should be redirected via a 300-class response.
The <accept> action element specifies the acceptable load via one of three sub-elements: <rate> (maximum requests/second), <percent> (fraction of requests to accept), or <win> (window size for window-based control). An optional "alt-action" attribute ("reject", "redirect", or "drop") governs what happens to excess requests.
The <call-identity> condition element and its sub-element <sip> identify requests to filter by SIP header fields: <from>, <to>, <request-uri>, and <p-asserted-identity>. Multiple <sip> sub-elements are OR-combined; multiple header-field sub-elements within <sip> are AND-combined.
The load-control event package name is "load-control", carried in the Event and Allow-Events SIP header fields per RFC 6665. It distributes load-filtering policies from notifiers (servers experiencing or anticipating overload) to subscribers (upstream load-filtering servers).
The <many-tel> and <except-tel> sub-elements extend the RFC 4745 identity model to support grouping of 'tel' URIs by a "prefix" attribute (common leading digits for global numbers, or phone-context value for local numbers), analogous to the "domain" attribute for SIP URIs.
The <method> condition element restricts load-filtering actions to a specific SIP method (INVITE, MESSAGE, REGISTER, SUBSCRIBE, OPTIONS, or PUBLISH). When omitted, filtering applies to all applicable initial requests.
The <target-sip-entity> condition element contains the URI of the entity that initiated the load-filtering policy (generally the notifier). It allows a filtering server with multiple routing paths to apply a policy only to requests destined for the specific overloaded entity rather than all matching requests.
This document registers the "application/load-control+xml" media type with IANA per RFC 6838. No required parameters; optional charset parameter same as application/xml (RFC 3023); file extension .xml.
This document registers the "load-control" SIP event package with IANA per RFC 6665 registration procedures.
This document registers the XML namespace "urn:ietf:params:xml:ns:load-control" and the XML schema "urn:ietf:params:xml:schema:load-control" with the IETF XML Registry per RFC 3688.
If notifiers can be spoofed, attackers can send fake notifications instructing subscribers to throttle all traffic, causing denial-of-service. Therefore, the load-filtering mechanism MUST be used within a Trust Domain. If a legitimate notifier within the domain is itself compromised, additional detection mechanisms are needed.
The "redirect" action can facilitate a reflection DoS attack: an attacker spoofing a central server's address could send NOTIFY bodies instructing proxy servers to redirect all calls to a victim outside the Trust Domain. Mitigation requires the Trust Domain to agree on permitted redirect destinations in advance, as specified in Section 3.4.
When identity fields in load-filtering conditions represent the source of a request (e.g., <from> or <p-asserted-identity>), they SHOULD be authenticated and authorized; when they represent the destination, authentication and authorization is optional.
The default NOTIFY body format for this event package is "application/load-control+xml". When a NOTIFY body is present but the SUBSCRIBE request carries no Accept header, the body MUST conform to this media type.
The load-control document is an XML document conforming to the namespace "urn:ietf:params:xml:ns:load-control", extending RFC 4745 Common Policy. The <ruleset> element carries mandatory "version" (non-negative 32-bit integer) and "state" ("full" or "partial") attributes to support ordered delivery and delta updates.