ltm rule namespace MR

iRule(1)					  BIG-IP TMSH Manual					     iRule(1)

MR
       Namespace MR

DESCRIPTION
       The MR namespace contains iRule commands that work with the message routing framework (MRF).

       MRF routes messages between two endpoints via a message routing proxy (MR proxy) associated with each
       endpoint.  Certain application layer protocols use the MRF to route protocol-specific messages.	A received
       message is said to "ingress" from one protocol-specific endpoint to the MR proxy.  A sent message is said to
       "egress" from the MR proxy to the protocol-specific endpoint.

       Associated Events:
	   MR_INGRESS  - Triggered when an incoming message reaches the MR proxy after the protocol filter.
	   MR_EGRESS   - Triggered when an outgoing message is ready to be sent to the protocol filter.
	   MR_FAIL     - Triggered when an outgoing message is unable to be routed.
	   MR_DATA     - Triggered when an incoming message has a streaming payload.

       MR iRule commands operate within a Tcl context associated with the connection flow between the endpoint and
       the MR proxy.  The ingress and egress parts of a message's journey therefore operate in separate Tcl contexts.
       The Tcl context contains the Tcl variables and execution state of the currently executing iRule event.  Only
       one iRule event can execute at a time on a connection flow, therefore messages queue to execute their iRule
       events.

       In many MR protocols, messages belong to independent transactions that are carried over the same network
       connection flow.  It is highly desirable for messages sharing a connection flow to execute their iRules
       independently of other messages.  This provides the following advantages and behavior changes:
	   * A message does not need to wait for an unrelated message to complete an event in order to execute its
       own event.
	   * Messages sharing a connection flow may exit the flow in a different order than they entered.
	   * Tcl variables cannot be overwritten between events by another message.  This capability may be enabled
       in the protocol-specific router profile via the irule-scope-message attribute, only for protocols that
       currently support it. For genericmessage, it may be enabled in the MR router profile.  Before enabling irule-
       scope-message for a protocol, the user's iRules should be examined and if necessary adjusted and tested, to
       ensure they do not rely on sharing a Tcl context between messages on a connection flow.

HINTS
SEE ALSO
BIG-IP						      2020-06-23					     iRule(1)