Hi Scott,
I see that while I was offline writing the following reply to you and
Bill Wagner, Jay Martin offered some more good thoughts and questions.
I think some of my comments below at least partially address some of
Jay's comments as well.
Hi Bill and Scott, Wednesday (16 April 1997)
My comments are imbedded in your two notes below. Because I'm prone to
sounding pedantic on communications issues, I'll apologize at the outset
and say that I applaud your patient work to wrestle with 'channels' (ie,
protocol stacks) in the Printer MIB. It would be nice if the IETF took
up this problem more generally (but without the level of 'statistics'
baggage which characterizes the IP/ICMP/TCP/UDP groups of MIB-II and the
the other lower-layer MIBs), but I am not aware that they have. Client
systems usually don't care about 'statistics' - they just care about the
communications paths (ie, addresses and protocol stacks used) to reach
other end systems (eg, network printers).
All of my comments are preceded by '<IEM>'.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
>---------------------- Included Messages -----------------------------<
>Date: Wed, 16 Apr 1997 15:08:08 PDT
>From: bwagner at digprod.com (Bill Wagner)
>Subject: Re: PMP> Novell Channel Type Info
>To: pmp at pwg.org>>> Scott,
>> Since this is an area in which I have some interest, I will provide
> what I understand to be answers consistent with what PMP has done. I
> cordially invite different opinions on what the consensus is, or what
> it should be.
>> 1. No objection
>> 2. Typically, the channel refers to the service or the 'highest' level
> protocol involved in delivering the print data to the printer.
> Therefore, chPortTCP(37) refers to a dumb TCP/IP connection of some
> undefined service on some host, to the interpreter. That is, there is
> no 'print service involved. Same thing for local ports such as serial,
> centronics and 1284.
>> If TCP/IP is used for IPP for example, the channel would be IPP. If
> IEEE 1284.1 is used over IEEE1284, the channel would be IEEE1284.1.
> Etc.
>> Each channel is correlated with the interface table in MIB-2, with the
> prtChannelIfIndex pointing to the particular listing in the MIB-2
> interface table that supports the channel. The Interface table has all
> the good stuff like physical address. It is also keyed to the other
> groups in MIB-2, including the IP group which includes the IP address
> and more.
<IEM>
In UNIX or embedded systems STREAMS-based protocol stacks, the application
which receives a packet from a TCP port (for example) does NOT receive
info about which physical interface (eg, 802.3 Ethernet vs 802.5 Token
Ring) passed that packet up to the IP network layer. Xerox engineers
believe that this is one of several instances where the Printer MIB
Channel table is 'broken' in its references to the Interfaces table (ie,
LPR has no clue whether the Ethernet or Token Ring LAN adapters delivered
a given job).
> Unfortunately, the integrity of this reference is not insured, since
> the relationship between the MIB-2 "device" and the printer is not
> well defined. Further, for unknown reasons, the printer MIB only
> requires the Systems group (which is useless with respect to a
> printer) and the interfaces group to be supported. Most printer
> implementations do support the applicable other groups of MIB-2 so
> that the IP is covered. But this is not required by the Printer MIB.
>> Yes, there is a hole with respect to IPX/SPX as well as all other non
> IP protocols. Some implementations have this filled in proprietary
> MIBS. Conceivably, the Netware MIB could be implemented, but I do not
> know if anyone is doing that. But does one really care about IPX/SPX
> addresses when one has the SAP names used?
>> 3. My suggestion with respect to the PServer was to simplify the
> handling of the channel table. A particular Print Server can be
> defined on multiple file servers (16 for DPI Print servers). This
> would require 16 channels. The purpose and advantage of this is
> unclear. The cumbersomeness is obvious. The information I suggested
> was the same as that used for RPrinter; if it is adequate for an
> RPrinter channel, I suggest that it is adequate for a PServer channel.
>>> 4, 5. Following the general approach, the interfaces could be enhanced
> so that more than one interface entry (e.g., IP, IPX) could be
> provided over one physical interface (ethernet). If this were done, a
> PServer channel running over IP would be correlated to an IP interface
> in the MIB-2 interface table. A PServer channel running over IPX would
> be correlated to an IPX interface.
<IEM>
RFC 1573 (Evolution of Interfaces group of MIB-II) defines a number of
new 'ifTypes', and an 'ifStackTable' (which inspired some proprietary
MIB work of mine, here at Xerox). But RFC 1573 specifically prohibits
the use of the 'ifTable' for protocol layers higher than datalink (OSI
layer 2). It says the 'ifStackTable' tells you the details BELOW an
IP (or other) network protocol (OSI layer 3). I haven't read the I-Ds
which update RFC 1573, but they are (after all) only I-Ds, so they
offer little help right now in finalizing the Printer MIB V2.
If a system implements the Interfaces Group per RFC 1213 (which is an
IETF Mandatory Standard), rather than updated per RFC 1573 (which is
merely an IETF Proposed Standard), then the 'ifPhysAddress' object ONLY
lists the address "at the protocol layer immediately 'below' the network
layer in the protocol stack". If a system (eg, Novell NetWare 4.x) is
running 802.2 LLC w/ SNAP, this address does NOT clearly map to any
802.3, 802.4, or 802.5 MAC layer address (because LLC addresses assume
a priori knowledge of the mapping from LLC or LLC_SNAP 'service access
points' to the 'underlying' MAC addresses on peer systems).
>> Alternatively, these may be independent channels on the same
> interface, differentiated by another keyword in the channel
> information object. But the distinction must provide some useful
> information, not just an academic follow through on the structure.
>> 6. Yes. Some implementations use a serverless IPX/SPX connection,
> with no print services in channel, to provide a connection between a
> user and a printer over which a print job (and response) is
> communicated.
>>> 7. As with Print Servers, if the distinction is important to a
> management application, the IP/IPC distinction could be handled by an
> additional keyword under channel information (and treating the two as
> separate channels) or conceivably by defining different interfaces in
> MIB-2. I agree that PMP should suggest a preferred way. An additional
> keyword, such as Protocol seems fine to me. But a given channel cannot
> be both.
<IEM>
The 'management application' our common client team here at Xerox builds
is an ordinary 'print client' (looking for suitable printers and how to
send jobs to them). Only a whole protocol stack is helpful.
>> Bill Wagner Osicom/DPI
>>>>______________________________ Reply Separator ________________________________
>_
>Subject: PMP> Novell Channel Type Info
>Author: "Scott A. Isaacson" <Scott_Isaacson at novell.com> at Internet
>Date: 4/16/97 12:57 PM
>>>Some comments about the draft and channel type info. Sorry to raise
>some questions about Channel Type and Channel Info again after all of
>these nice quite, peaceful months with no comments...
>>General Question:
>There is a wide mix of Channel types defined: some relatively high in a
>layered protocol stack (application protocols) and some lower
>(transports) and some even lower (hardware interfaces). What if some
>of the higher layer application protocols can run over multiple transports?
>Do we need to put into each channel type info which transport it is
>currently configured to run over or which transports it may run over or
>do we not define which transports are used? It is easy for some (FTP
>will run over TCP), but for some of the Netware channel types (PServer
>and NDPS) they will run over TCP or SPX. What do we include in the
>channel info for these channel types?
>>1. Page 37
>Editorial: The use of the term PServer has several changes in
>capitalization: Pserver, PServer. Make them all consistent. Suggest
>PServer
> chNetwareRPrinter(9), -- Novell, Inc.
> -- prtChannelInformation keywords:
> -- Print Server Name
> -- Keyword: "PServer"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity: Single
> -- Description: The PServer's SAP name
> --
> -- Printer Number
> -- Keyword: "Printer"
> -- Syntax: Integer
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The printer number
> -- There must be one PServer and one
> -- Printer entry
>>2. Page 37
>Question:
>If the channel type is chPortTCP(37), the only parameter identified for
>channel info is "port". Is it assumed that the IP address is already
>known? Also for all of the other TCP/IP based channels (FTP, HTTP,
>etc.), is it assumed that the IP address is already known because you
>are using SNMP to talk to the Printer? What if you are using SNMP over
>IPX to get the at the MIB, is there somewhere else to ask it its IP address?
>>I ask this because if the channel type is this one, chNetwareRPrinter(9),
>the transport protocol used is SPX. Do you also want to know the full
>IPX/SPX address for this node, i.e., net:node:socket?
>Should we add a paramenter called "Address" or is the IPX/SPX address
>obtainable from somewhere else?
>>3. Page 37 an 38
>There has been some discussion lately about this. Bill W. proposed
>something recently that I have just now had a chance to take a
>better look at and I have some revisions to his suggestion:
>> chNetwarePServer(10), -- Novell, Inc.
> -- prtChannelInformation keywords:
> -- Server Name
> -- Keyword: "Server"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The name of the server for
> -- which the PServer is defined
> --
> -- PServer
> --
> -- Name: "PServer"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The Bindery name of the
> -- PServer
> --
> -- NDS Tree
> --
> -- Keyword: "NDSTree"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Multiple
> -- Description: The NDS Tree name
> --
> -- PServer
> --
> -- Keyword: "NDSPServer"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The fully qualified name
> -- of the PServer object in the tree
> --
> -- There must be exactly one Server and
> -- one PServer entry or exactly one NDSTree
> -- and one NDSPServer Entry
>>4. Page 108
>The following line:
> -- Netware Print Server SPX/IPX based channel
>should probably be:
> -- Netware Print Server NCP based channel
>See comments below about NCP over IPX and IP.
>>5. Page 107
>Page 107 states:
> "-- The Print Job Delivery Channel table describes the
> -- capabilities of the printer and not what is currently being
> -- performed by the printer"
>In the next release of IntranetWare, NCPs will be able to run over both IP
>and IPX. When that is the case, shouldn't the channel info also include
>the possible IP address as well as the IPX address or just the fact that it
>can run over IP or IPX? This relates to my earlier questions about where
>the IP and IPX addresses are retrieved: are they just known or ar the
>queried in a MIB someplace?
<IEM>
Yes, I agree that the distinctions in the 'underlying' protocol stacks
are cogent.
>>Do we need to add something like:
> -- Keyword: "Protocol"
> -- Syntax: Name
> -- Status: Mandatory
> -- Multiplicity Multiple
> -- Description: Either "IP" or "IPX" or both
> --
>6. Page 41
>Will anyone ever populate a channel type of just SPX as compared to
>NPrinter or PServer? Why do we have chPortSPX(41) separated out?
>Should it be part of chNetwareNPrinter and chNetwarePServer?
>> chPortSPX(41), -- Sequenced Packet Exchange (SPX)
> -- socket.
> -- Novell, Inc. Similar to TCP, a
> -- bi-directional data pipe using
> -- Novell SPX as a transport.
> --
> -- prtChannelInformation keywords:
> --
> -- Network Number
> --
> -- Keyword: "Net"
> -- Syntax: HexString
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The network number
> --
> -- Node Number
> --
> -- Keyword: "Node"
> -- Syntax: HexString
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The Node Number
> --
> -- Socket Number
> --
> -- Keyword: "Socket"
> -- Syntax: HexString
> -- Status: Mandatory
> -- Multiplicity Single
> -- Description: The SPX socket number
> -- There must be exactly one "Net" and one
> -- "Node" and one Socket entry. A HexString
> -- and one "Socket" entry. A HexString is a
> -- binary value represented as a string of
> -- ASCII characters using hexadecimal
>>7. Page 42
>NDPS can run over TCP or SPX. Do I need to add a parameter to chNDPS
>to describe which transports are possible or is that the purpose of this
>channel info?
<IEM>
Does NDPS only operate over one 'flavor' of RPC? Probably a dumb question,
but perhaps relevant. Certainly some other ISO DPA-based systems operate
over more than one 'flavor' of RPC (eg, ONC RPC vs DCE RPC). Might also
need to be made explicit.
>>That all for now,
>Scott
>************************************************************
>Scott A. Isaacson
>Print Services Consulting Engineer
>Novell Inc., 122 E 1700 S, Provo, UT 84606
>V: (801) 861-7366, (800) 453-1267 x17366
>F: (801) 861-4025, E: scott_isaacson at novell.com>W: http://www.novell.com>************************************************************