Re: SNMP over X.25
Fred Baker <fbaker@acc.com> Thu, 11 August 1994 22:55 UTC
Received: from ietf.nri.reston.va.us 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 dg-rtp.rtp.dg.com by CNRI.Reston.VA.US id aa16988; 11 Aug 94 18:55 EDT
Received: from fennel.acc.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA09786; Thu, 11 Aug 1994 18:04:17 -0400
Received: from by fennel.acc.com (4.1/SMI-4.1) id AB24615; Thu, 11 Aug 94 14:56:23 PDT
Message-Id: <9408112156.AB24615@fennel.acc.com>
X-Sender: fbaker@129.192.64.25
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 11 Aug 1994 14:56:24 -0800
To: Melnikov@iae.nsk.su
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Subject: Re: SNMP over X.25
Cc: x25mib@dg-rtp.dg.com
> 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
- SNMP over X.25 Aleksey V. Melnikov
- Re: SNMP over X.25 Fred Baker