CHOICE {
globalId [2] IMPLICIT OBJECT IDENTIFIER,
localId [3] IMPLICIT INTEGER
}
The "globalId" form of ActionTypeId is required if scoping is used
(i.e., the value of the scope field is other than "baseObject").
7.3.11. Time Fields
The "eventTime" field of the m-EventReport Invoke PDU and the m-
EventConfirmedReport Invoke PDU must be present.
The "currentTime" field of the following PDUs must be present: the
m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set
Result PDU, the m-Action Confirmed Result PDU, the m-Create Result
PDU, the m-Delete Result PDU, the GetListError Error PDU, and the
SetListError Error PDU.
All CMIP time fields shall use the ASN.1 GeneralizedTime type defined
in [5] with 1 millisecond granularity.
If the system generating the PDU does not have the current time, yet
does have the time since last boot, then GeneralizedTime can be used
to encode this information. The time since last boot will be added
to the base time "0001 Jan 1 00:00:00.00" using the Gregorian
calendar algorithm. (In the Gregorian calendar, all years have 365
days except those divisible by 4 and not by 400, which have 366.) The
use of the year 1 as the base year will prevent any confusion with
current time.
If no meaningful time is available, then the year 0 shall be used in
GeneralizedTime to indicate this fact.
7.3.12. Response PDUs
Both the "managedObjectClass" and "managedObjectInstance" fields must
be present in the following CMIP response PDUs: the m-EventReport
Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the
m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete
Result PDU, the GetListError Error PDU, and the SetListError Error
PDU. The "managedObjectInstance" field must be present in the
ProcessingFailure Error PDU. The "managedObjectClass" field must be
present in the NoSuchArgument Error PDU.
7.3.13. Error PDUs
The "globalId" form of AttributeId is required for the
NoSuchAttributeId Error PDU and the InvalidAttributeValue Error PDU.
8. Association Control Service Element
The Association Control Service Element (ACSE), which is necessary
for establishing and releasing application associations, is defined
in [7] and [8].
8.1. ACSE Services
The ACSE service description is detailed in ISO 8649 [7]. All of the
defined ACSE services are mandatory:
o A-ASSOCIATE: This confirmed service is used to initiate an
application association between application entities.
o A-RELEASE: This confirmed service is used to release an
application association between application entities without
loss of information.
o A-ABORT: This unconfirmed service causes the abnormal release
of an association with a possible loss of information.
o A-P-ABORT: This provider-initiated service indicates the
abnormal release of an application association by the
underlying presentation service with a possible loss of
information.
Mappings of the ACSE services to presentation services and ACSE APDUs
are shown in Table 6, along with a section reference to ISO 8649 [7].
+-------------+------------+----------------------+-------------+
| ACSE | ISO 8649 | Related | Associated |
| Service | Reference | Presentation Service | APDUs |
+-------------+------------+----------------------+-------------+
| A-ASSOCIATE | 9.1 | P-CONNECT | AARQ, AARE |
| A-RELEASE | 9.2 | P-RELEASE | RLRQ, RLRE |
| A-ABORT | 9.3 | P-U-ABORT | ABRT |
| A-P-ABORT | 9.4 | P-P-ABORT | (none) |
+-------------+------------+----------------------+-------------+
Table 6. Mapping of ACSE Services
8.2. Supporting Services
ACSE will make use of the following ISO presentation layer services:
P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT. These presentation
services will be provided by the LPP [13].
8.3. ACSE Protocol
The ACSE protocol specification is found in ISO 8650 [8]. All five
ACSE APDUs specified in the standard are mandatory.
8.3.1. Application Context Name
The Application Context Name takes the form of an OBJECT IDENTIFIER.
The value of this OBJECT IDENTIFIER includes both the version of CMOT
being used for this association and the version number of the highest
version of the Internet-standard MIB supported by the manager or
agent. The application context name has the following generic form:
{ iso(1) org(3) dod(6) internet(1) mgmt(2) mib(n)
cmot(9) cmotVersion(1) version-number(v) }
where n = highest MIB version supported and
v = version of CMOT supported
For the version of CMOT defined in these agreements, "version-number"
has the value of one (1). This version of CMOT implies the versions
of the ISO protocols specified in this memo (see Figure 2).
8.3.2. User Information
The following CMIS M-INITIALISE parameters are all mapped onto the
ACSE User Information parameter: Functional Units, User Information,
and Access Control. (See section 7.1.4 for more information on the
CMIS M-INITIALISE parameters.) ACSE User Information is defined in
ISO 8650 as follows:
Association-information ::= SEQUENCE OF EXTERNAL
The ASN.1 defined type EXTERNAL, which is defined in section 35 of
ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification
and an associated ASN.1 encoding.
The OBJECT IDENTIFIER and syntax associated with the ACSE Functional
Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is
defined as { iso(1) standard(0) ips-osi-mips(9596) cmip(2) version(1)
acse(0) functional-units(0) } and the syntax is a BIT STRING.
The EXTERNAL definition for User Information is left unspecified at
this time; it will be defined in a future memo.
If some form of access control is required, a simple unencrypted
password can be used. The EXTERNAL for this simple access control
will use the OBJECT IDENTIFIER { cmotAcseAccessControl } (Appendix A)
and the syntax OCTET STRING. A more sophisticated authentication
mechanism will be defined with another EXTERNAL definition in a
future memo.
8.3.3. Presentation Service Parameters
The values and defaults of parameters to the ACSE primitives that are
given to the presentation service are specified in RFC1085 [13].
For the Presentation Context Definition List parameter to the P-
CONNECT service [13, p. 10], the value of the Abstract Syntax Name
associated with the Presentation Context Identifier of value one (1)
shall be identical to the OBJECT IDENTIFIER used for the Application
Context Name (section 8.3.1).
The Quality of Service parameter shall have the value of either
"tcp-based" or "udp-based."
9. Remote Operations Service Element
The Remote Operations Service Element (ROSE), which provides the
ability to invoke remote operations, is specified in ISO 9072-1 [9]
and 9072-2 [10]. ROSE can only be used once an association has been
established between two application entities. ROSE is used to
support CMISE; it is not intended to be used directly by management
application processes.
9.1. ROSE Services
The ROSE service definition is detailed in ISO 9072-1 [9]. All of
the defined ROSE services are mandatory:
o RO-INVOKE: This unconfirmed service is used by an invoking
ROSE-user to cause the invocation of an operation to be
performed by an invoked ROSE-user.
o RO-RESULT: This unconfirmed service is used by an invoked
ROSE-user to reply to a previous RO-INVOKE indication in the
case of a successfully performed operation.
o RO-ERROR: This unconfirmed service is used by an invoked
ROSE-user to reply to a previous RO-INVOKE indication in the
case of an unsuccessfully performed operation.
o RO-REJECT-U: This unconfirmed service is used by a ROSE-user
to reject a request (RO-INVOKE indication) of the other
ROSE-user if it has detected a problem. It may also be used
by a ROSE-user to (optionally) reject a reply (RO-RESULT
indication, RO-ERROR indication) from the other ROSE-user.
o RO-REJECT-P: This provider-initiated service is used to advise
a ROSE-user of a problem detected by the ROSE-provider.
Mappings of ROSE services to ISO presentation services and ROSE APDUs
are shown in Table 7, along with a section reference to ISO 9072-1
[9].
+-------------+------------+----------------------+-------------+
| ROSE | ISO 9072-1 | Related | Associated |
| Service | Reference | Presentation Service | APDUs |
+-------------+------------+----------------------+-------------+
| RO-INVOKE | 10.1 | P-DATA | ROIV |
| RO-RESULT | 10.2 | P-DATA | RORS |
| RO-ERROR | 10.3 | P-DATA | ROER |
| RO-REJECT-U | 10.4 | P-DATA | RORJ |
| RO-REJECT-P | 10.5 | P-DATA | RORJ |
+-------------+------------+----------------------+-------------+
Table 7. Mapping of ROSE Services
9.2. Supporting Services
ROSE will only make use of the presentation layer service P-DATA.
This service is provided by the LPP. The following restrictions are
a consequence of the use of the LPP: First, mappings to the Reliable
Transfer Service Element (RTSE) are not possible, since no RTSE is
present. Second, no data token is used with the presentation
services.
9.3. ROSE Protocol
The protocol specification for ROSE shall follow ISO 9072-2 [10].
All four APDUs specified in the standard are mandatory. In addition,
the ability to support the correct origination and reception of the
linked-id protocol element is required if the multiple reply
functional unit has been selected (section 7.1.2).
9.3.1. Operation Class
Since no turn management is required by ROSE, the Operation Class
parameter may be ignored.
9.3.2. Priority
ROSE will deliver each APDU in a "first in, first out" manner. Since
no turn management is required by ROSE, the Priority parameter may be
ignored.
10. Lightweight Presentation
The specification for the lightweight presentation protocol (LPP) is
contained in RFC1085, "ISO Presentation Services on top of TCP/IP-
based internets" [13]. The services defined in that memo are the
minimal set of ISO presentation services required to support ACSE and
ROSE. The protocol specified to provide these services is a
replacement for the ISO presentation protocol.
10.1. Lightweight Presentation Services
All of the ISO presentation services provided by the LPP are
mandatory: P-CONNECT, P-RELEASE, P-U-ABORT, P-P-ABORT, and P-DATA.
10.2. Supporting Services
Depending on the quality of service indicated in the P-CONNECT
request, the LPP will use either UDP (low quality) or TCP (high
quality) as the underlying transport protocol. UDP provides an
unreliable datagram service, while TCP provides a reliable
connection-oriented transport service.
Practically speaking, there are two ways to discover whether a remote
system supports the LPP over UDP or TCP. The first is to use some
undefined form of directory service. This might be nothing more than
a local table. The second way is simply to attempt to establish an
association with the remote application entity using the desired
quality of service. If the transport for that service is unavailable
on the remote system, then the local presentation-service-provided
will issue a negative P-CONNECT.CONFIRMATION primitive. This will be
interpreted by ACSE as a failure to establish an association with the
desired quality of service.
The following well-known UDP and TCP port numbers are defined:
cmot manager 163/tcp
cmot manager 163/udp
cmot agent 164/tcp
cmot agent 164/udp
When UDP is used, an implementation need not accept a lightweight
presentation PDU whose length exceeds 484. The purpose of this
restriction is to ensure that CMIP requests and responses can be
transmitted in a single unfragmented IP datagram.
10.3. Lightweight Presentation Protocol
No further agreements are needed for the lightweight presentation
protocol defined in RFC1085.
11. Acknowledgements
This RFCis the work of many people. The following members of the
IETF Netman working group and other interested individuals made
important contributions:
Amatzia Ben-Artzi, 3Com
Asheem Chandna, AT&T Bell Laboratories
Ken Chapman, Digital Equipment Corporation
Anthony Chung, Sytek
George Cohn, Ungermann-Bass
Gabriele Cressman, Sun Microsystems
Pranati Kapadia, Hewlett-Packard
Lee LaBarre, The MITRE Corporation (chair)
Dave Mackie, 3Com
Keith McCloghrie, The Wollongong Group
Jim Robertson, 3Com
Milt Roselinsky, CMC
Marshall Rose, The Wollongong Group
John Scott, Data General
Lou Steinberg, IBM
12. References
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC1052, April 1988.
[2] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC1065,
August 1988.
[3] McCloghrie, K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC1066,
August 1988.
[4] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
Network Management Protocol (SNMP)", RFC1098, (Obsoletes
RFC1067), April 1989.
[5] ISO 8824: "Information processing systems - Open Systems
Interconnection, Specification of Abstract Syntax Notation One
(ASN.1)", Geneva, March 1988.
[6] ISO 8825: "Information processing systems - Open Systems
Interconnection, Specification of Basic Encoding Rules for
Abstract Notation One (ASN.1)", Geneva, March 1988.
[7] ISO 8649: "Information processing systems - Open Systems
Interconnection, Service Definition for Association Control
Service Element".
[8] ISO 8650: "Information processing systems - Open Systems
Interconnection, Protocol Specification for Association
Control Service Element".
[9] CCITT Recommendation X.219, Working Document for ISO 9072-1:
"Information processing systems - Text Communication, Remote
Operations: Model, Notation and Service Definition",
Gloucester, November 1987.
[10] CCITT Recommendation X.229, Working Document for ISO 9072-2:
"Information processing systems - Text Communication, Remote
Operations: Protocol Specification", Gloucester,
November 1987.
[11] ISO DIS 9595-2: "Information processing systems - Open
Systems Interconnection, Management Information Service
Definition - Part 2: Common Management Information
Service", 22 December 1988.
[12] ISO DIS 9596-2: "Information Processing Systems - Open
Systems Interconnection, Management Information Protocol
Specification - Part 2: Common Management Information
Protocol", 22 December 1988.
[13] Rose, M., "ISO Presentation Services on top of TCP/IP-based
internets", RFC1085, December 1988.
[14] OSI Network Management Forum, "Forum Interoperable Interface
Protocols", September 1988.
[15] ISO DIS 7498-4: "Information processing systems - Open
Systems Interconnection, Basic Reference Model - Part 4:
OSI Management Framework".
[16] ISO/IEC JTC1/SC21/WG4 N571: "Information processing systems -
Open Systems Interconnection, Systems Management: Overview",
London, July 1988.
[17] Klerer, S. Mark, "The OSI Management Architecture: An
Overview", IEEE Network Magazine, March 1988.
[18] Ben-Artzi, A., "Network Management for TCP/IP Networks: An
Overview", Internet Engineering Task Force working note,
April 1988.
[19] ISO/IEC JTC1/SC21/WG4 N3324: "Information processing
systems - Open Systems Interconnection, Management
Information Services - Structure of Management
Information - Part I: Management Information Model",
Sydney, December 1988.
[20] Postel, J., "User Datagram Protocol", RFC768, August 1980.
[21] Postel, J., "Transmission Control Protocol", RFC793,
September 1981.
[22] ISO DP 9534: "Information processing systems - Open Systems
Interconnection, Application Layer Structure", 10 March 1987.
[23] Rose, M., "ISO Transport Services on top of the TCP",
RFC1006, May 1987.
[24] ISO 8822: "Information processing systems - Open Systems
Interconnection, Connection Oriented Presentation Service
Definition", June 1987.
[25] Postel, J., "Internet Protocol", RFC791, September 1981.
[26] CCITT Draft Recommendation X.500, ISO DIS 9594/1-8: "The
Directory", Geneva, March 1988.
Appendix A - The CMOT Group
CMOT DEFINITIONS ::= BEGIN
IMPORTS OBJECT-TYPE FROM RFC1065-SMI;
IMPORTS mib FROM RFC1066-MIB;
cmot OBJECT IDENTIFIER ::= { mib 9 }
-- The following assignments are made for the purpose of
-- identification within CMOT and do not refer to MIB objects.
cmotVersion OBJECT IDENTIFIER ::= { cmot 1 }
cmotAcseInfo OBJECT IDENTIFIER ::= { cmot 2 }
cmotAcseAccessControl OBJECT IDENTIFIER ::= { cmotAcseInfo 1 }
-- The following definition is made for use in referencing a
-- managed system (for the purpose of proxy management) in the
-- CMIP Object Instance field. It does not represent a MIB
-- object.
cmotSystemID OBJECT-TYPE
SYNTAX CmotSystemID
ACCESS not-accessible
STATUS optional
::= { cmot 3 }
CmotSystemID ::= CHOICE {
arbitrary [0] IMPLICIT OCTET STRING,
proxyIndex [1] IMPLICIT INTEGER,
inetAddr [2] IMPLICIT IpAddress,
domainName [3] IMPLICIT OCTET STRING,
mac802Addr [4] IMPLICIT OCTET STRING,
x121Addr [5] IMPLICIT OCTET STRING,
nsap [6] IMPLICIT OCTET STRING,
netbiosName [7] IMPLICIT OCTET STRING,
snaName [8] IMPLICIT OCTET STRING,
adminId [9] IMPLICIT OBJECT IDENTIFIER
}
-- All addresses should be conveyed in network-byte order.
END
Appendix B - Management Information Summary
RFC1066-MIB-INTERPRETATION
{ iso org(3) dod(6) internet(1) mgmt(2) 1 }
DEFINITIONS ::= BEGIN
IMPORTS mgmt, OBJECT-TYPE FROM RFC1065-SMI;
mib OBJECT IDENTIFIER ::= { mgmt 1 }
system OBJECT IDENTIFIER ::= { mib 1 }
interfaces OBJECT IDENTIFIER ::= { mib 2 }
at OBJECT IDENTIFIER ::= { mib 3 }
ip OBJECT IDENTIFIER ::= { mib 4 }
icmp OBJECT IDENTIFIER ::= { mib 5 }
tcp OBJECT IDENTIFIER ::= { mib 6 }
udp OBJECT IDENTIFIER ::= { mib 7 }
egp OBJECT IDENTIFIER ::= { mib 8 }
-- definition of object class
OBJECT-CLASS MACRO ::=
BEGIN
TYPE NOTATION ::= SubClassOf Superiors Names Attributes
VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)
SubClassOf ::= "SUBCLASS OF" value(OBJECT-CLASS)
| empty
Superiors ::= "SUPERIORS" "{" SuperiorList "}"
| empty
Names ::= "NAMES" "{" AttributeList "}"
| empty
Attributes ::= "CONTAINS" "{" AttributeList "}"
| empty
SuperiorList ::= Superior | Superior "," SuperiorList
Superior ::= value(OBJECT-CLASS)
AttributeList ::= Attribute | Attribute "," AttributeList
Attribute ::= value(OBJECT-TYPE)
END
-- the System group
system OBJECT-CLASS
NAMES { cmotSystemID } -- Appendix A
CONTAINS {
sysDescr,
sysObjectID,
sysUpTime
}
::= { mib 1 }
-- the Interfaces group
interfaces OBJECT-CLASS
SUPERIORS { system }
CONTAINS { ifNumber }
::= { mib 2 }
ifTable OBJECT-CLASS
SUPERIORS { interfaces }
::= { interfaces 2 }
ifEntry OBJECT-CLASS
SUPERIORS { ifTable }
NAMES { ifIndex }
CONTAINS {
ifIndex,
ifDescr,
ifType,
ifMtu,
ifSpeed,
ifPhysAddress,
ifAdminStatus,
ifOperStatus,
ifLastChange,
ifInOctets,
ifInUcastPkts,
ifInNUcastPkts,
ifInDiscards,
ifInErrors,
ifInUnknownProtos,
ifOutOctets,
ifOutUcastPkts,
ifOutNUcastPkts,
ifOutDiscards,
ifOutErrors,
ifOutQLen
}
::= { ifTable 1 }
-- the Address Translation group
at OBJECT-CLASS
SUPERIORS { system }
::= { mib 3 }
atTable OBJECT-CLASS
SUPERIORS { at }
::= { at 1 }
atEntry OBJECT-CLASS
SUPERIORS { atTable }
NAMES {
atIfIndex,
atNetAddress
}
CONTAINS {
atIfIndex,
atPhysAddress,
atNetAddress
}
::= { atTable 1 }
-- the IP group
ip OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
ipForwarding,
ipDefaultTTL,
ipInReceives,
ipInHdrErrors,
ipInAddrErrors,
ipForwDatagrams,
ipInUnknownProtos,
ipInDiscards,
ipInDelivers,
ipOutRequests,
ipOutDiscards,
ipOutNoRoutes,
ipReasmTimeout,
ipReasmReqds,
ipReasmOKs,
ipReasmFails,
ipFragOKs,
ipFragFails,
ipFragCreates
}
::= { mib 4 }
-- the IP Interface table
ipAddrTable OBJECT-CLASS
SUPERIORS { ip }
::= { ip 20 }
ipAddrEntry OBJECT-CLASS
SUPERIORS { ipAddrTable }
NAMES { ipAdEntAddr }
CONTAINS {
ipAdEntAddr,
ipAdEntIfIndex,
ipAdEntNetMask,
ipAdEntBcastAddr
}
::= { ipAddrTable 1 }
-- the IP Routing table
ipRoutingTable OBJECT-CLASS
SUPERIORS { ip }
::= { ip 21 }
ipRouteEntry OBJECT-CLASS
SUPERIORS { ipRoutingTable }
NAMES { ipRouteDest }
CONTAINS {
ipRouteDest,
ipRouteIfIndex,
ipRouteMetric1,
ipRouteMetric2,
ipRouteMetric3,
ipRouteMetric4,
ipRouteNextHop,
ipRouteType,
ipRouteProto,
ipRouteAge
}
::= { ipRoutingTable 1 }
-- the ICMP group
icmp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
icmpInMsgs,
icmpInErrors,
icmpInDestUnreachs,
icmpInTimeExcds,
icmpInParmProbs,
icmpInSrcQuenchs,
icmpInRedirects,
icmpInEchos,
icmpInEchoReps,
icmpInTimestamps,
icmpInTimestampReps,
icmpInAddrMasks,
icmpInAddrMaskReps,
icmpOutMsgs,
icmpOutErrors,
icmpOutDestUnreachs,
icmpOutTimeExcds,
icmpOutParmProbs,
icmpOutSrcQuenchs,
icmpOutRedirects,
icmpOutEchos,
icmpOutEchoReps,
icmpOutTimestamps,
icmpOutTimestampReps,
icmpOutAddrMasks,
icmpOutAddrMaskReps
}
::= { mib 5 }
-- the TCP group
tcp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
tcpRtoAlgorithm,
tcpRtoMin,
tcpRtoMax,
tcpMaxConn,
tcpActiveOpens,
tcpPassiveOpens,
tcpAttemptFails,
tcpEstabResets,
tcpCurrEstab,
tcpInSegs,
tcpOutSegs,
tcpRetransSegs
}
::= { mib 6 }
-- the TCP connections table
tcpConnTable OBJECT-CLASS
SUPERIORS { tcp }
::= { tcp 13 }
tcpConnEntry OBJECT-CLASS
SUPERIORS { tcpConnTable }
NAMES {
tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort
}
CONTAINS {
tcpConnState,
tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemAddress,
tcpConnRemPort
}
::= { tcpConnTable 1 }
-- the UDP group
udp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
udpInDatagrams,
udpNoPorts,
udpInErrors,
udpOutDatagrams
}
::= { mib 7 }
-- the EGP group
egp OBJECT-CLASS
SUPERIORS { system }
CONTAINS {
egpInMsgs,
egpInErrors,
egpOutMsgs,
egpOutErrors
}
::= { mib 8 }
-- the EGP Neighbor table
egpNeighTable OBJECT-CLASS
SUPERIORS { egp }
::= { egp 5 }
egpNeighEntry OBJECT-CLASS
SUPERIORS { egpNeighTable }
NAMES { egpNeighAddr }
CONTAINS {
egpNeighState,
egpNeighAddr
}
::= { egpNeighTable 1 }
END
Appendix C - Sample Protocol Exchanges
The following are sample protocol exchanges between a manager and an
agent. The manager establishes an association with the agent,
requests the number of IP address and header errors, requests the
type of route corresponding to the destination address 10.0.0.51,
requests the TCP connection with the well-known port for FTP, and
then releases the association. All of these samples show the
lightweight presentation protocol being used over TCP.
--
-- the manager sends an ACSE association request carried in a
-- presentation connect request PDU
--
{
connectRequest { -- LPP
version version-1,
reference {
callingSSUserReference "sri-nic.arpa",
commonReference "880821222531Z"
},
asn 1.3.6.1.2.1.9.1.1,
user-data { -- ACSE
protocol-version version1,
application-context-name 1.3.6.1.2.1.9.1.1,
user-information {
functionalUnits {
direct-reference 1.0.9596.2.1.0.0,
encoding {
single-ASN1-type '010110101010101010110B'
-- Full Manager
}
}
}
}
}
}
--
-- the agent sends an ACSE association response carried in a
-- presentation connect response PDU
--
{
connectResponse { -- LPP
user-data {
user-information { -- ACSE
functionalUnits {
direct-reference 1.0.9596.2.1.0.0,
encoding {
single-ASN1-type '101001010101010101110B'
-- Full Agent
}
}
}
}
}
}
--
-- the manager sends a get request to read the values of
-- ipInHdrErrors and ipInAddrErrors
--
{
userData { -- LPP
ro-Invoke { -- ROSE
invokeID 10,
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ip { 1.3.6.1.2.1.4 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {}
}
},
attributeIdList {
attributeId {
localID 4 -- ipInHdrErrors
},
attributeId {
localID 5 -- ipInAddrErrors
}
}
}
}
}
}
--
-- the agent replies with a get response indicating that
-- ipInHdrErrors = 0 and ipInAddrErrors = 2
--
{
userData { -- LPP
ro-Result { -- ROSE
invokeID 10,
{
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ip { 1.3.6.1.2.1.4 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {}
}
},
currentTime "19880821222541.300000Z",
attributeList {
attribute {
attributeId {
localID 4 -- ipInHdrErrors
},
attributeValue 0
},
attribute {
attributeId {
localID 5 -- ipInAddrErrors
},
attributeValue 2
}
}
}
}
}
}
}
--
-- the manager sends a get request to discover the ipRouteType for
-- the IP routing entry with ipRouteDest = 10.0.0.51
--
{
userData { -- LPP
ro-Invoke { -- ROSE
invokeID 11,
operation-value m-Get (3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {
attributeValueAssertion {
attributeType ipRouteDest
{ 1.3.6.1.2.1.4.21.1.1 },
attributeValue 10.0.0.51
}
}
}
},
attributeIdList {
attributeId {
localID 8 -- ipRouteType
}
}
}
}
}
}
--
-- the agent replies with a get response indicating the appropriate
-- route type
--
{
userData { -- LPP
ro-Result { -- ROSE
invokeID 11,
{
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {
attributeValueAssertion {
attributeType ipRouteDest
{ 1.3.6.1.2.1.4.21.1.1 },
attributeValue 10.0.0.51
}
}
}
},
currentTime "19880821222613.780000Z",
attributeList {
attribute {
attributeId {
localID 8 -- ipRouteType
},
attributeValue "direct"
}
}
}
}
}
}
}
--
-- the manager sends a get request to read the TCP connection with
-- the well-known port for FTP.
--
{
userData { -- LPP
ro-Invoke { -- ROSE
invokeID 12,
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm tcpConnTable { 1.3.6.1.2.1.6.13 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName { }
}
},
scope oneLevel(1),
filter {
item {
equality {
attributeType tcpConnLocalPort
{ 1.3.6.1.2.1.6.13.1.3 }
attributeValue 21 -- ftp
}
}
}
attributeIdList { } -- an empty list means all attributes
}
}
}
}
--
-- the agent replies with a get response providing the desired TCP
-- connection information. If more than one TCP connection had
-- satisfied the filter condition, a series of one or more linked
-- reply PDUs would have been returned before the final get response.
--
{
userData { -- LPP
ro-Result { -- ROSE
invokeID 12,
{
operation-value m-Get(3),
argument { -- CMIP
baseManagedObjectClass {
globalForm tcpConnEntry { 1.3.6.1.2.1.6.13.1 }
},
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName {
attributeValueAssertion {
attributeType { tcpConnLocalAddress },
attributeValue 128.10.0.34
},
attributeValueAssertion {
attributeType { tcpConnLocalPort },
attributeValue 21
},
attributeValueAssertion {
attributeType { tcpConnRemAddress },
attributeValue 0.0.0.0
},
attributeValueAssertion {
attributeType { tcpConnRemPort },
attributeValue 0
},
}
}
},
currentTime "19880821222541.300000Z",
attributeList {
attribute {
attributeId {
localId 1 -- tcpConnState
},
attributeValue LISTEN
},
attribute {
attributeId {
localId 2 -- tcpConnLocalAddress
},
attributeValue 128.10.0.34
},
attribute {
attributeId {
localId 3 -- tcpConnLocalPort
},
attributeValue 21
},
attribute {
attributeId {
localId 4 -- tcpConnRemAddress
},
attributeValue 0.0.0.0
},
attribute {
attributeId {
localId 5 -- tcpConnRemPort
},
attributeValue 0
}
}
}
}
}
}
}
--
-- the manager sends a presentation release request
--
{
releaseRequest { -- LPP
user-data { -- ACSE
reason normal
}
}
}
--
-- the agent sends a presentation release response
--
{
releaseResponse { -- LPP
user-data { -- ACSE
reason normal
}
}
}
Authors' Addresses
Unnikrishnan S. Warrier
Unisys Corporation
2400 Colorado MS #42-13
Santa Monica, CA 90406
Phone: (213) 453-5196
Email: unni@cs.ucla.edu
Larry Besaw
Hewlett-Packard
3404 East Harmony Road
Fort Collins, CO 80525
Phone: (303) 229-6022
Email: lmb%hpcndaw@hplabs.hp.com