Re: SNMP over X.25

Fred Baker <> Thu, 11 August 1994 22:55 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa14942; 11 Aug 94 18:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14938; 11 Aug 94 18:55 EDT
Received: from by CNRI.Reston.VA.US id aa16988; 11 Aug 94 18:55 EDT
Received: from by (5.4R2.01/dg-rtp-v02) id AA09786; Thu, 11 Aug 1994 18:04:17 -0400
Received: from by (4.1/SMI-4.1) id AB24615; Thu, 11 Aug 94 14:56:23 PDT
Message-Id: <>
X-Sender: fbaker@
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 11 Aug 1994 14:56:24 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <>
Subject: Re: SNMP over X.25

>    Solution you have proposed is very understandable, but I would
>    like to find a way to use X.25 protocol as direct transport for
>    SNMP (in your terms: SNMP/X.25). The same as IPX or DDP could
>    be optional transport protocol for mapping SNMPv2 (according to
>    RFC 1449). Is it possible ?

It's possible but not currently defined. You would basically carry the SNMP
PDU around as a complete packet sequence, and you would make the connection
to an appropriate process (identified by a NLPID or SNAP header in the Call
User Data) in the switch. You need to define the NLPID.

>> The one issue is that you have to assign an IP address to Packet
>> Switch C.
>    In this case Packet Switch software have to be able to resolve
>    IP and UDP protocols, could I avoid it ?

You will have to handle the SNMP data anyway, no reason not to service IP
and UDP. The software would terminate them as a host does, but this is not
a major issue: you could have a canned header that consists of

        name                    contents
        ____                    ________
        IP version/length       0x45
        TOS                     0x00
        packet length           = 20 + 8 + SNMP PDU Length
        identifier              sequence number
        fragment field          0x00 0x00
        time to live            0xFF
        protocol identifier     0x11
        checksum                = ones complement sum of words in IP header
        source address          configured value
        destination address     derived from request you're responding to

        UDP source PORT         161 (0xA1)
        UDP Destination port    derived from request you're responding to
        UDP data length         = 8 + SNMP PDU Length
        UDP checksum            00 00 or calculated checksum

packet processing:

        connection opens with first octet of call user data == 0xCC

        a complete packet sequence arrives on that connection

        verify that:

                IP version/length == 0x45
                packet length == size of packet sequence
                message is not fragmented (or reassemble fragments)
                protocol identifier == 0x11
                IP header checksum verifies
                source address == configured value

                UDP destinaton PORT == 161 (0xA1)
                UDP data length == IP Data Length - 20
                UDP checksum is zero or verifies

        given that, save the source ip address and udp port; write them
        into the destination fields of the canned header.

        do what you would have to do anyway for X.25 native SNMP [big deal]

        prepend the canned header on the resulting SNMP PDU, calculating
        the two lengths and at least one checksum, and incrementing the
        sequence number in the identification field.

        send result as a complete packet sequence on the same connection the
        request came in on.

This addresses one other thing that you had in your original note;
interoperability with the TCP/IP domain. If the thing at the other end of
the X.25 VC is an IP router, this interoperability falls out.

                        "In sound wisdom there are two sides"
                                        Zophar, Job 11:6