Connected: An Internet Encyclopedia
RFC 1445 - 2.7. Proxy Relationship

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1445
Up: 2. Elements of the Model
Prev: 2.6. MIB View
Next: 2.8. SNMPv2 Context

### 2.7. Proxy Relationship

A proxy relationship exists when, in order to process a received management request, a SNMPv2 entity must communicate with another, logically remote, entity. A SNMPv2 entity which processes management requests using a proxy relationship is termed a SNMPv2 proxy agent.

When communication between a logically remote party and a SNMPv2 entity is via the SNMPv2 (over any transport protocol), then the proxy party is called a SNMPv2 native proxy relationship. Deployment of SNMPv2 native proxy relationships is a means whereby the processing or bandwidth costs of management may be amortized or shifted - thereby facilitating the construction of large management systems.

When communication between a logically remote party and a SNMPv2 entity party is not via the SNMPv2, then the proxy party is called a SNMPv2 foreign proxy relationship. Deployment of foreign proxy relationships is a means whereby otherwise unmanageable devices or portions of an internet may be managed via the SNMPv2.

The transparency principle that defines the behavior of a SNMPv2 entity in general applies in particular to a SNMPv2 proxy relationship:

The manner in which one SNMPv2 entity processes SNMPv2 protocol messages received from another SNMPv2 entity is entirely transparent to the latter.

The transparency principle derives directly from the historical SNMP philosophy of divorcing architecture from implementation. To this dichotomy are attributable many of the most valuable benefits in both the information and distribution models of the Internet-standard Network Management Framework, and it is the architectural cornerstone upon which large management systems may be built. Consistent with this philosophy, although the implementation of SNMPv2 proxy agents in certain environments may resemble that of a transport-layer bridge, this particular implementation strategy (or any other!) does not merit special recognition either in the SNMPv2 management architecture or in standard mechanisms for proxy administration.

Implicit in the transparency principle is the requirement that the semantics of SNMPv2 management operations are preserved between any two SNMPv2 peers. In particular, the "as if simultaneous" semantics of a Set operation are extremely difficult to guarantee if its scope extends to management information resident at multiple network locations. For this reason, proxy configurations that admit Set operations that apply to information at multiple locations are discouraged, although such operations are not explicitly precluded by the architecture in those rare cases where they might be supported in a conformant way.

Also implicit in the transparency principle is the requirement that, throughout its interaction with a proxy agent, a management station is supplied with no information about the nature or progress of the proxy mechanisms by which its requests are realized. That is, it should seem to the management station - except for any distinction in underlying transport address - as if it were interacting via SNMPv2 directly with the proxied device. Thus, a timeout in the communication between a proxy agent and its proxied device should be represented as a timeout in the communication between the management station and the proxy agent. Similarly, an error response from a proxied device should - as much as possible - be represented by the corresponding error response in the interaction between the proxy agent and management station.

Next: 2.8. SNMPv2 Context

Connected: An Internet Encyclopedia
RFC 1445 - 2.7. Proxy Relationship