home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dcom / cellrel / 676 < prev    next >
Encoding:
Text File  |  1992-11-09  |  2.1 KB  |  50 lines
  1. Newsgroups: comp.dcom.cell-relay
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!kronos.arc.nasa.gov!iscnvx!news
  3. From: myoung@force.ssd.lmsc.lockheed.com
  4. Subject: SNMP and DIagnostics
  5. Message-ID: <1992Nov9.141013.6243@iscnvx.lmsc.lockheed.com>
  6. Sender: news@iscnvx.lmsc.lockheed.com (News)
  7. Reply-To: myoung@force.ssd.lmsc.lockheed.com
  8. Organization: LMSC, Sunnyvale, California
  9. Date: Mon, 9 Nov 92 14:10:13 GMT
  10. Lines: 38
  11.  
  12. SNMP
  13.  
  14. The SNMP community must have considered mechanisms for supporting SNMP 
  15. objects over cell relay.  Path tables, node parameters, and physical 
  16. device parameters must be read as SNMP objects.
  17.  
  18. Currently SNMP is designed for TCP/IP support, but I think some work
  19. is being done to make SNMP protocol independent at that layer.  Have
  20. the SNMP vendors signed onto the SSCOP signaling layer as a carrier
  21. protocol?  
  22.  
  23. And Diagnostics:
  24.  
  25. At a deeper level, what about sniffer protocols? Don't we need some
  26. capability to snoop through the virtual path tables, following some
  27. path down its multi-hop links, reading out the path tables in route,
  28. possibly splitting the snooper packet as the virtual path splits in a
  29. one to many circuit.  Or how about finding a route around a particular 
  30. physical link, then passing data through the link, bringing back the 
  31. results for verification.  Or how about building a branch from an existing 
  32. path, and bring the cell stream to some embedded protocol analyzer.
  33.  
  34. It seems that the sniffer protocols would need some more elementary 
  35. access to the path tables, not wanting to rely on SCCOP which it
  36. might be testing.
  37.  
  38. Why Not:
  39.  
  40. SCCOP must have some exploratory "pinging" protocol which it uses to
  41. discover new links, check for new nodes and build nearest neighbor maps.
  42. Why isn't this pinging protocol enhanced and made generally available
  43. as a programmable layer?
  44.  
  45. There is a lot of software and a lot of protocols available already,
  46. as well as companies with proprietary requirements.  Why not allow this
  47. existing base of technology and distribution be ported directly to
  48. the switches, operating their own signaling systems?  Why duplicate
  49. existing software?
  50.