RFC 1095
Common Management Information Services and Protocol over TCP/IP (CMOT)
5. Management Information The description of management information has two aspects. First, a structure of management information (SMI) defines the logical structure of management information and how it is identified and described. Second, the management information base (MIB), which is specified using the SMI, defines the actual objects to be managed. The purpose of this section is to show how CMIP is used in the CMOT architecture to convey information defined in the Internet MIB.
5.1. The Structure of Management Information The SMI supplies the model for understanding management information, as well as templates and ASN.1 macros that can be used for defining actual management information. The following sections discuss the ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI in terms of the ISO SMI so that CMIP can be used to carry management information defined in terms of the Internet SMI. 5.1.1. The ISO SMI The ISO SMI [19] is based on the abstraction of a "managed object" and the various kinds of relationships objects can be involved in. The following discussion does not purport to be a complete and accurate description of the latest ISO SMI work. It is intended to be a clear presentation of the basic ISO SMI concepts essential for understanding the CMIP-specific interpretation of the Internet SMI presented in section 5.3. 5.1.1.1. Managed Objects and Attributes Management Information is modeled using object-oriented techniques. All "things" in the network that are to be managed are represented in terms of managed objects. A "managed object" is an abstraction (or logical view) for the purposes of network management of a "manageable" physical or logical resource of the network. In this context, "manageable" means that a particular resource can be managed by using CMIP. Examples of managed objects are protocol entities, modems, and connections. Each managed object belongs to a particular object class. An "object class" represents a collection of managed objects with the same, or similar, properties. A particular managed object existing in a particular network is defined as an "object instance" of the object class to which it belongs. Thus, an object instance represents an actual realization of an object class (i.e., a managed object of a particular class bound to specific values). An example of an object class is "transport connection." In an actual network, there are a number of managed objects (specific transport connections) that are instances of this class. In summary, a managed object type, which is called an "object class," is the collection of all actual and potential instances of that type. Managed objects are fully defined by specifying the "attributes" or properties the object has, the CMIS operations that can be performed on the object (e.g., M-SET, M-CREATE) and any constraints on those operations, specific actions (e.g., self-test) that can be performed on the object, events that the object can generate, and information
about various relationships the object may be involved in. All of this information relevant to a managed object is typically provided by filling in an object template. Managed objects contain properties that are referred to as attributes. Attributes are atomic items of information that can only be manipulated as a whole. An example of an attribute is a counter providing a specific piece of information, such as the number of packets retransmitted. Each object class and attribute is assigned a unique identifier (an ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration authority. 5.1.1.2. Management Information Hierarchies Managed objects participate in relationships with each other. There are two relationships that are of particular importance for management information: the containment relationship and the inheritance relationship. These relationships can be used to construct hierarchies of managed objects. In addition, there is another hierarchy defined by the registration process for registering identifiers for object classes and attributes. 5.1.1.2.1. The Registration Hierarchy The registration hierarchy is determined by the ASN.1 registration tree [5] for assigning OBJECT IDENTIFIERs. An OBJECT IDENTIFIER is an administratively assigned name composed of a series of integers traversing a path from the root of the ASN.1 registration tree to the node or leaf to be identified. For example, the sequence of integers { iso(1) standard(0) ips-osi-mips(9596) cmip(2) } (1.0.9596.2) can be used to uniquely identify the CMIP standard. Each node of this tree has an associated registration authority that determines how numbers in the subtree defined by that node are allocated. In the context of management, these OBJECT IDENTIFIERs are used for identifying object classes and attributes. The registration hierarchy is not based on any particular relationship between managed objects or between managed objects and their attributes. It is independent of both the inheritance and containment relationships described below. Its purpose is simply to generate universally unique identifiers. 5.1.1.2.2. The Containment Hierarchy The containment hierarchy is constructed by applying the relationship "is contained in" to objects and attributes. Objects of one class may contain objects of the same or different class. Objects may also contain attributes. Attributes cannot contain objects or other
attributes. For example, objects of the class "transport entity" may
contain objects of the class "transport connection"; an object of the
class "management domain" may contain objects of the class "node." An
object class that contains another object class is called the
"superior" object class; an object class that is contained in another
object class is called the "subordinate" object class. The
containment relationships that an object may participate in are part
of the definition of the object class to which that managed object
belongs. All object classes (except the topmost) must have at least
one possible superior in the containment tree. The definition of a
class may permit it to have more than one such superior. However,
individual instances of such a class are nevertheless contained in
only one instance of a possible containing class.
The containment hierarchy is important because it can be used for
identifying instances of a managed object. For example, assume there
is an object class "domain" that contains an object class "node" that
contains an object class "transport entity" that contains an object
class "transport connection." A particular instance of a transport
connection can be identified by the concatenation of "instance
information" for each object class in the containment path: {
domain="organization," node="herakles," transport entity=tp4,
transport connection=<TSAP-AddressA, TSAP-AddressB> }.
What constitutes appropriate "instance information" for each object
class is part of the definition of that object class and is known as
the "distinguished attribute(s)." A distinguished attribute is
composed of an OBJECT IDENTIFIER naming the attribute and the value
of the attribute. For each object class, the distinguished
attributes that differentiate instances of that class are
collectively called the "relative distinguished name." A sequence of
relative distinguished names (one for each class in the containment
path) is the "distinguished name" of a managed object. The example
given above represents the distinguished name of a transport
connection. The containment hierarchy is sometimes referred to as
the "naming tree", because it is used to "name" a particular instance
of a managed object.
The containment relationship also defines an existence dependency
among its components; an object or attribute can "exist" only if the
containing object also "exists." Deletion of an object may result in
deletion of all objects and attributes contained within it.
Alternately, depending on the definition of the managed object,
deletion may be refused until all contained managed objects have been
deleted.
5.1.1.2.3. The Inheritance Hierarchy The inheritance hierarchy is constructed by applying the relationship "inherits properties of" to object classes. An object class may inherit properties of another object class; refinement is obtained by adding additional properties. In this relationship, the parent class is called the "superclass" and the inheriting class the "subclass." For example, the class "layer entity" may be a superclass of "network entity," which in turn is a superclass of "X.25 network entity." Attributes defined for "network entity" (e.g., the number of packets sent) are automatically defined for "X.25 network entity" without having to explicitly include them in the definition for the class "X.25 network entity." Thus, inheritance serves as a shorthand for defining object classes using object-oriented methodology. Each class (except the topmost) has at least one superclass, but may have zero, one, or many subclasses. Subclasses may in turn have further subclasses, to any degree. A special object called "top" is the ultimate superclass. It has no properties of its own. The inheritance hierarchy has no relevance to the naming of object instances. It is useful only insofar as it leads to a manageable and extensible technique for the definition of object classes. 5.1.2. The Internet SMI The Internet SMI [2] is designed to be a protocol-independent SMI that can be used with both SNMP and CMIP. For this reason, it is necessary for any management protocol that uses this SMI to show how it is to be interpreted in a protocol-specific manner. This is done for CMIP in this memo. The Internet SMI indicates both how to identify managed objects and how to define them. The Internet SMI defines a registration subtree rooted at { iso(1) org(3) dod(6) internet(1) } for the sake of registering OBJECT IDENTIFIERs to be used for uniquely identifying managed objects. The current Internet SMI specifies the format for defining objects in terms of an "object type" template and an associated OBJECT-TYPE ASN.1 macro. An object type definition contains five fields: a textual name, along with its corresponding OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of the object type; an access (read-only, read-write, write-only, or not-accessible); and a status (mandatory, optional, or obsolete). The current Internet SMI does not provide any mechanism for defining actions or events associated with a managed object. In describing management information, the current Internet SMI does not use the notions of "object class" and "attribute" found in the ISO SMI. Only the concepts of "object type" and "object instance"
are used. The Internet SMI shows how to define object types; it leaves the specification of object instances as a protocol-specific matter. The current Internet structure of management information is simpler and less rich than the corresponding ISO structure. The ISO SMI makes a distinction between simple "attributes," which can be viewed as "leaf objects" that are the lowest elements of the containment hierarchy, and composite "managed objects" that belong to an "object class" and have a structure associated with them (that is, can contain attributes). The Internet SMI does not draw this distinction; both simple and composite "objects" are defined as "object types." What structure is associated with objects in the Internet SMI is defined through the deliberate attempt to structure the lower part of the Internet registration tree according to containment principles. (Objects that are considered "attributes" of other containing objects are defined directly below them in the object registration tree.) This results in a certain lack of flexibility, since the registration hierarchy is implicitly used to define the containment hierarchy. This means that the Internet SMI does not contain a mechanism for defining containment relationships that do not happen to coincide with the registration hierarchy. In interpreting the Internet SMI for use with CMIP, it is necessary to overcome this limitation. 5.2. The Management Information Base The Management Information Base (MIB) is a "conceptual repository of management information." It is an abstract view of all the objects in the network that can be managed. Note that the MIB is conceptual in that it does not carry any implications whatsoever about the physical storage (main memory, files, databases, etc.) of management information. The SMI provides the guidelines for defining objects contained in the MIB. The CMOT approach will use the Internet MIB based on the Internet SMI described above. The first version of the Internet MIB, which is the product of the IETF MIB working group, is defined in RFC 1066 [3]. It contains objects divided into eight groups: system, interfaces, address translation, IP, ICMP, TCP, UDP, and EGP. In addition, the Internet SMI provides for future versions of the Internet MIB and a means for otherwise extending the MIB through the registration of managed objects under "private" and "experimental" branches of the object registration tree. Appendix B provides a protocol-specific interpretation of the first version of the TCP/IP MIB defined in [3] so that it can be used with CMOT. This interpretation is based on a straightforward mapping of the current Internet SMI to the ISO SMI (section 5.3). The initial version of the Internet MIB concentrates on defining
objects associated with various Internet protocols. It is expected that future versions of the Internet MIB and various extensions will provide a much richer set of objects to manage, including management information about a variety of network devices and systems. Thus, an expanded MIB will allow wide-ranging and powerful management using the CMOT approach. 5.3. An Interpretation of the Internet SMI In order to use CMIP to convey information defined in terms of the Internet SMI, it is necessary to show how object instances are specified and to provide the necessary structure for differentiating object class and attributes. These objectives are both met by separating the containment hierarchy used for naming objects from the registration hierarchy and by imposing an "object class" structure on the Internet SMI. Using the technique of imposing an object class structure does not replace or redefine the object definitions in the Internet MIB; it merely provides a necessary gloss or commentary on a MIB defined in terms of the Internet SMI. For example, Appendix B references the "object type" definitions found in [3], but imposes additional structure on them. This object class definition derives from a simplified version of the OBJECT-CLASS macro defined in the ISO SMI [19]. The more complex definition is not needed for present purposes. (The object class definition presented here could be extended in the future to show what actions and events are associated with a managed object.) The object class definition has the following fields: OBJECT CLASS: ------------ A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object class, along with its corresponding OBJECT IDENTIFIER. Definition: A textual description of the object class. Subclass Of: The OBJECT CLASS DESCRIPTOR of the object class that is the superclass of this object class. This field is used for indicating the inheritance relationship. Superiors: A list of OBJECT CLASS DESCRIPTORs of the possible superior object classes of this object class. This field is used for indicating the containment relationship.
Names:
A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
the distinguished attributes of this object class. (The OBJECT-
TYPE macro is defined in RFC 1065). Attributes listed here will
normally be present in the Attribute field of the object class
definition. This field is used for indicating what attributes
must be present in the relative distinguished name that indicates
an instance of this object class.
Attributes:
A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
attributes of this object class. (The OBJECT-TYPE macro is defined
in RFC 1065). This field is used for indicating the attributes
that are contained in this object class.
This object class definition satisfies our objectives for
interpreting the Internet SMI for use by CMIP. The Attributes
field shows what attributes are contained in this object class;
this makes the necessary distinction between object classes and
attributes required by CMIP. Instead of referencing an
"attribute" def inition (as is done in the ISO SMI), the
Attributes field references the "object type" definition found in
RFC 1065 and used to define the Internet-standard MIB in RFC 1066.
The name, syntax, and access information required for attributes
is contained in the "object type" definition. Two things are
required for specifying an instance of a managed object: a
containment relationship determining a sequence of object classes
and a means for specifying the distinguished attributes for an
object class. The Superiors field makes the containment
relationship explicit; it is no longer merely a function of the
registration tree. The Names field makes it possible to indicate
the distinguished attributes for an object class required for
giving instance information. Thus, the object class definition
makes it possible to specify an object instance using CMIP.
5.3.1. Object Class and Attributes
The mapping of management information to the CMIS parameters Managed
Object Class and Attribute Identifier List now becomes apparent.
5.3.1.1. Object Class
The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER
assigned to the particular object class. For example, the Managed
Object Class for the object class "ip" (as defined in Appendix B) is
{ mib 4 } = 1.3.6.1.2.1.4.
5.3.1.2. Attribute Identifier The CMIS Attribute Identifier List parameter is a list of Attribute Identifiers. An Attribute Identifier can be either global or local. If it is global, then it is the OBJECT IDENTIFIER assigned to the attribute (i.e., "object type") that is being indicated. For example, the global Attribute Identifier for the attribute "ipForwarding" (as defined in [3]) is { ip 1 } = 1.3.6.1.2.1.4.1. If the Attribute Identifier is local, it is an integer that is the last component in the OBJECT IDENTIFIER identifying the object. For ipForwarding, the local Attribute Identifier is 1. In the case where the local identifier is used, the leading components of the OBJECT IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the containing object class. This is true for the interpreted Internet MIB defined in Appendix B, but may not be true generally. The local identifier is intended to be interpreted relative to the Managed Object Class field of the CMIP PDU. When a local Attribute Identifier is encountered in a CMIP PDU, the global form of the identifier is formed by prepending the OBJECT IDENTIFIER in the Managed Object Class field to the local identifier. This is valid only when scoping is not used (i.e., scoping is "baseObject"). If scoping is used, then the global form of the Attribute Identifier must be used instead of the local form. 5.3.2. Management Information Hierarchies The following sections show how the three management information hierarchies are to be understood for the interpreted Internet SMI. 5.3.2.1. The Registration Hierarchy The registration hierarchy is the global object registration tree described in [2]. It is used merely for assigning identifiers for object classes and attributes (i.e., "object types" in RFC 1065). 5.3.2.2. The Containment Hierarchy As described above, the containment hierarchy is used to specify an object instance. The Names field of the object class definition contains the distinguished attributes for the object class. The OBJECT IDENTIFIER naming the "attribute" together with its value is called an attribute value assertion. A set of attribute value assertions (one for each distinguished attribute) is the relative distinguished name associated with that object class. The sequence of relative distinguished names for each of the object classes in the
containment hierarchy to which a managed object belongs is the
distinguished name of the object. An object instance is fully
specified by a distinguished name.
Let us take a concrete example from Appendix B. How would we
represent an instance of an entry in the IP routing table? We begin
by examining the object class in question (ipRouteEntry) and use the
Superiors field to find the superior class in the containment
hierarchy (ipRoutingTable). This process continues until we
construct the following containment path of object classes: system,
ip, ipRoutingTable, ipRouteEntry. Now for each of these object
classes, we inspect the Names field to find the distinguished
attribute for that object class. If no Names field is present (as is
the case for "ip" and "ipRoutingTable"), then no instance information
is required at that level. Both "system" and "ipRouteEntry" have
Name fields to show what information is expected at that level. With
this information, we can construct the following distinguished name
specifying an instance of an IP routing table entry:
baseManagedObjectInstance {
distinguishedName {
relativeDistinguishedName { -- system
attributeValueAssertion {
attributeType { cmotSystemID }
attributeValue "gateway1.acme.com"
}
},
relativeDistinguishedName { -- ipRouteEntry
attributeValueAssertion {
attributeType { ipRouteDest }
attributeValue 10.0.0.51
}
}
}
}
If the system instance information is not present, then it is assumed
to be the system with which the management association is established
(i.e., the system receiving the request).
Note that the object instance tree can contain components of the
distinguished name that are outside the managed system (node). This
enables referencing of objects across management domains (there could
be an object class "domain") and across a collection of nodes. In a
network where several intermediate managers may be involved in a
request, each intermediate manager can use the "system" portion of
the name to determine where to send a request or result. This technique of naming treats each intermediate managing system as a proxy manager. The proxy manager resolves the address of the next node in the chain and may use a different protocol to transfer the request or result. Thus, the "system" instance information can be used to name devices being managed by proxy. 5.3.2.3. The Inheritance Hierarchy The Internet SMI does not use the inheritance relationship. The "Subclass Of" field is present in the object class definition to show how the inheritance relationship would be represented and to allow for future extensibility. It is not used for any of the object classes defined in Appendix B. 5.4. Scoping, Filtering, and Synchronization Within some services, CMIS provides additional capabilities that are related to the SMI. These are the scoping, filtering, synchronization, and linked-reply facilities. The presence of these facilities are indicated by the Multiple Object Selection Functional Unit defined in CMIS [11]. These facilities provide the manager with the ability to operate on a collection of managed objects, rather than a single object. The selection of multiple objects occurs in two phases: scoping and filtering. Scoping is used to identify the managed objects to which a filter is to be applied. Then filtering is used to select a subset of managed objects that satisfy certain conditions. If scoping is not used, only the "base" managed object indicated by the CMIS Managed Object Class parameter is implied. An example of the use of scoping and filtering for selecting a particular managed object (a table entry) is given in one of the sample protocol exchanges found in Appendix C. 5.4.1. Scoping Scoping is meant to be understood in terms of the containment hierarchy. A position at a certain level of the containment tree is defined by the CMIS Managed Object Class parameter. The CMIS Scope parameter is then interpreted relative to this "base" managed object (defined by both object class and object instance). The Scope parameter can be used to select the base object alone, all managed objects in the entire subtree (of the containment tree) below the base object, or all managed objects in the "n"th level (n = 1, 2, 3,...) below the base object.
5.4.2. Filtering Within the objects selected as a result of the scope parameter, it is possible to further refine the selection of managed objects through the use of filtering. Filtering provides the ability to select a subset of these objects based on conditions applied to attributes (e.g., IP routing table entries with the "ipRouteAge > 100") and logical operations (and, or, not). 5.4.3. Synchronization When multiple managed objects have been selected using scoping and filtering, the question of synchronization across object instances (such as multiple IP routing table entries) arises. The two possible choices are "best effort" and "atomic." If "best effort" synchronization is selected, the failure to apply an operation (e.g., M-SET) to one instance of an object does not affect the effort to apply this operation to other instances of the object. If "atomic" synchronization is selected, then the operation is either performed on all object instances selected or none. The default synchronization is best effort. 5.4.4. Linked Replies If the reply to a single request for a set of managed objects results in more than one managed object being returned, all of these managed objects cannot be returned together in a single CMIP response PDU. The reason for this is that the structure of the CMIP response PDU only has a single field for containing object instance information. Since each managed object has its own instance information, each managed object must be returned in a separate CMIP PDU. In such a case, the CMIP Linked Reply PDU is used. The Linked Reply PDU provides a means of associating each of the multiple replies with the original request that generated them. Thus, a single CMIP Get Request PDU that uses scoping and filtering would result in zero or more CMIP Linked Reply PDUs being returned before a final CMIP Get Result PDU. A linked reply can also be used to segment a CMIP response pertaining to a single managed object. This would only be necessary if UDP is being used as the underlying transport and it is not possible to return all the information requested about the managed object in a single response PDU subject to the size limitations described in section 10.2. 5.5. Accessing Tables This section explains how to use the interpreted Internet SMI and MIB
to access tables. 5.5.1. Accessing Whole Tables A whole table is accessed by specifying the object class of the table, indicating a scoping level of one, and not providing an attribute identifier list. The CMIS standard [11] specifies that if the attribute identifier parameter is not present, then all attribute identifiers are assumed. The following CMIS parameters would be used to return the entire TCP connection table: Object Class: { tcpConnTable } Object Instance: "empty" (unless proxy management is used) Scope: oneLevel(1) Filter: not present Attribute Identifier List: not present By scoping one level below "tcpConnTable," all managed objects of the class "tcpConnEntry" are selected. (The object class "tcpConnEntry" is the only object class one level below the object class "tcpConnTable" in the containment hierarchy.) The absence of an attribute identifier list signals that all attributes of the managed object are to be returned (i.e., all fields of the TCP connection table entry). In reply to this request, each entry of the table will be returned in a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU). Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and the appropriate Object Instance information for that entry, as well as an Attribute List giving the values of each of the fields of the table entry. 5.5.2. Accessing Table Entries An entire table entry is accessed by specifying the object class of the table entry, providing a distinguished name specifying the instance of the table entry, and not providing an attribute identifier list. As seen above, the absence of the attribute identifier list parameter indicates that all attributes are assumed. The absence of a scope parameter indicates that the base managed object class is intended. The following CMIS parameters would be used to return the entire IP routing table entry for which the field "ipRouteDest" has the value 10.0.0.51: Object Class: { ipRouteEntry } Object Instance: { ipRouteDest, 10.0.0.51 } Scope: not present Filter: not present
Attribute Identifier List: not present
The result is returned in a single CMIP Get Result PDU with an
attribute list consisting of all of the attributes (i.e., fields) of
the table entry and their corresponding values.
If the object class field refers to a table entry and no instance
information is provided to select a particular entry, then a
"noSuchObjectInstance" CMIP error should be returned.
Part II: Protocol Agreements
6. CMOT Protocol Overview
This part of the document is a specification of the protocols of the
CMOT architecture. Contained herein are the agreements required to
implement interoperable network management systems using these
protocols. The protocol suite defined by these implementors'
agreements will facilitate communication between equipment of
different vendors, suppliers, and networks. This will allow the
emergence of powerful multivendor network management based on ISO
models and protocols.
The choice of a set of protocol standards together with further
agreements needed to implement those standards is commonly referred
to as a "profile." The selection policy for the CMOT profile is to
use existing standards from the international standards community
(ISO and CCITT) and the Internet community. Existing ISO standards
and draft standards in the area of OSI network management form the
basis of this CMOT profile. Other ISO application layer standards
(ROSE and ACSE) are used to support the ISO management protocol
(CMIP). To ensure interoperability, certain choices and restrictions
are made here concerning various options and parameters provided by
these standards. Internet standards are used to provide the
underlying network transport. These agreements provide a precise
statement of the implementation choices made for implementing ISO
network management standards in TCP/IP-based internets.
In addition to the Netman working group, there are at least two other
bodies actively engaged in defining profiles for interoperable OSI
network management: the National Institute of Science and Technology
(NIST) Network Management Special Interest Group (NMSIG) and the OSI
Network Management Forum. Both of these groups are similar to the
Netman working group in that they are each defining profiles for
using ISO standards for network management. Both differ in that they
are specifying the use of underlying ISO protocols, while the Netman
working group is concerned with using OSI management in TCP/IP
networks. In the interest of greater future compatibility, the
Netman working group has attempted to make the CMOT profile conform
as closely as possible to the ongoing work of these two bodies.
6.1. The CMOT Protocol Suite
The following seven protocols compose the CMOT protocol suite: ISO
ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation
protocol (LPP), UDP, TCP, and IP. The relation of these protocols to
each other is briefly summarized in Figure 2.
+----------------------------------------------+
| Management Application Processes |
+----------------------------------------------+
+-------------------+
| CMISE |
| ISO DIS 9595/9596 |
+-------------------+
+------------------+ +--------------------+
| ACSE | | ROSE |
| ISO IS 8649/8650 | | ISO DIS 9072-1/2 |
+------------------+ +--------------------+
+-----------------------------------------------+
| Lightweight Presentation Protocol (LPP) |
| RFC 1085 |
+-----------------------------------------------+
+------------------+ +--------------------+
| TCP | | UDP |
| RFC 793 | | RFC 768 |
+------------------+ +--------------------+
+-----------------------------------------------+
| IP |
| RFC 791 |
+-----------------------------------------------+
Figure 2. The CMOT Protocol Suite
6.2. Conformance Requirements
A CMOT-conformant system must implement the following protocols:
ACSE, ROSE, CMIP, LPP, and IP. A conformant system must support the
use of the LPP over either UDP or TCP. The use of the LPP over both
UDP and TCP on the same system may be supported. A conformant system
need not support all CMIS operations. A conformant system must,
however, support at least one of the functional unit groups
(indicating a set of supported services) defined in section 7.1.3.
The service and protocol selections are described in greater detail
in the following sections.
6.3. Abstract Syntax Notation
The abstract syntax notation for all of the application service
elements of the CMOT protocol suite is Abstract Syntax Notation One
(ASN.1) [5]. The LPP is also defined using ASN.1. The basic
encoding rules used for ASN.1 are specified in [6]. Both definite- length and indefinite-length encodings are expressly permitted. 7. Common Management Information Service Element The Common Management Information Service Element (CMISE) is specified in two ISO documents. The service definition for the Common Management Information Service (CMIS) is given in ISO DIS 9595-2 [11]. The protocol specification for the Common Management Information Protocol (CMIP) is found in ISO DIS 9596-2 [12]. 7.1. CMIS Services 7.1.1. CMIS Services Overview All of the CMIS services listed in Table 1 are allowed with the CMOT approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET, M-SET, M-ACTION, M-CREATE, and M-DELETE. The specific services supported by a system will be determined by the functional unit group or groups to which a system belongs. 7.1.2. Functional Units The CMIS services supported are designated in terms of functional units [11]. Each functional unit corresponds to the invoker or performer aspect of a particular service. (The terms "invoker" and "performer" are taken from ROSE and refer to the caller of and responder to a remote operation, respectively.) The "stand alone" functional units associated with each of the management services are given in Table 2 as functional units 0-17. The number following the name of each functional unit in the table is defined by CMIP [12] to identify that particular functional unit. The functional units are used by the CMISE-service-user at the time of association establishment to indicate which services it is willing to support.
+---------------------------------+------------------------+------+
| Functional Unit | Service Primitives | Mode |
+---------------------------------+------------------------+------+
| conf. event report invoker(0) | M-EVENT-REPORT Req/Conf| C |
| conf. event report performer(1) | M-EVENT-REPORT Ind/Rsp | C |
| event report invoker(2) | M-EVENT-REPORT Req | U |
| event report performer(3) | M-EVENT-REPORT Ind | U |
| confirmed get invoker(4) | M-GET Req/Conf | N/A |
| confirmed get performer(5) | M-GET Ind/Rsp | N/A |
| confirmed set invoker(6) | M-SET Req/Conf | C |
| confirmed set performer(7) | M-SET Ind/Rsp | C |
| set invoker(8) | M-SET Req | U |
| set performer(9) | M-SET Ind | U |
| confirmed action invoker(10) | M-ACTION Req/Conf | C |
| confirmed action performer(11) | M-ACTION Ind/Rsp | C |
| action invoker(12) | M-ACTION Req | U |
| action performer(13) | M-ACTION Ind | U |
| confirmed create invoker(14) | M-CREATE Req/Conf | N/A |
| confirmed create performer(15) | M-CREATE Ind/Rsp | N/A |
| confirmed delete invoker(16) | M-DELETE Req/Conf | N/A |
| confirmed delete performer(17) | M-DELETE Ind/Rsp | N/A |
| multiple reply(18) | Linked Identification | N/A |
| multiple object selection(19) | Scope, Filter, Sync. | N/A |
| extended service(20) | Extended Presentation | N/A |
+---------------------------------+------------------------+------+
C = confirmed, U = non-confirmed, N/A = not applicable
Table 2. Functional Units
In addition to the stand alone functional units, there are three
additional functional units. If any of these additional functional
units are selected, then at least one of the stand alone functional
units must be selected. The multiple reply functional unit makes
available the use of the linked identification parameter in the
selected stand alone functional units. This makes possible the use
of linked reply (multiple CMIP PDU responses to a single request).
The multiple object selection functional unit makes available the use
of the scope, filter, and synchronization parameters in the selected
stand alone functional units. If the multiple object selection
functional unit is selected, then the multiple reply functional unit
must also be selected. The extended services functional unit makes
available presentation layer services in addition to the P-DATA
service. Selecting this functional unit has no effect in the context
of CMOT, since the lightweight presentation layer provides only
minimal ISO presentation services.
7.1.3. Functional Unit Groups In order to assist in the reduction of code size and complexity for different types of devices, a number of "functional unit groups" have been defined. Each of these groups indicates a set of services defined for either a manager or an agent. The "negotiation" concerning which functional unit groups are supported is done by means of the Functional Units parameter of the M-INITIALISE service (see section 7.1.4.1). There are five functional unit groups for managers: Event Monitor, Monitoring Manager, Simple Manager, Controlling Manager, and Full Manager. Each functional unit group is a superset of the preceding group. There are five functional unit groups for agents: Event Sender, Monitored Agent, Simple Agent, Controlled Agent, and Full Agent. Again, each functional unit group is a superset of the preceding group. The operations supported for each functional unit group are summarized in Table 3. +--------------------+------+-----+-----+-------+------+-----+------+ | |Event | Get | Set |Create/|Action|Mult.|Mult. | |Functional Unit |Report| | |Delete | |Reply|Object| |Groups | | | | | | |Select| +--------------------+------+-----+-----+-------+------+-----+------+ | 1. Event Monitor | U | no | no | no | no | no | no | | 2. Event Sender | U | no | no | no | no | no | no | | 3. Monitoring Mgr. | U | yes | no | no | no | no | no | | 4. Monitored Agent | U | yes | no | no | no | no | no | | 5. Simple Manager | U | yes | C | no | no | yes | no* | | 6. Simple Agent | U | yes | C | no | no | yes | no* | | 7. Controlling Mgr.| U | yes | U/C | yes | no | yes | yes | | 8. Controlled Agent| U | yes | U/C | yes | no | yes | yes | | 9. Full Manager | U/C | yes | U/C | yes | U/C | yes | yes | |10. Full Agent | U/C | yes | U/C | yes | U/C | yes | yes | +--------------------+------+-----+-----+-------+------+-----+------+ C = confirmed, U = non-confirmed * Simple Managers and Agents must support "oneLevel" scoping for all and only those cases where it is required to access a whole table and may support synchronization other than "best effort"; no support for filtering is required. Table 3. Functional Unit Groups A conformant system must support at least one of these functional unit groups. A system may support both a manager group and an agent group. A system only needs to implement the services and service primitives required for the groups that it supports. In addition, a system may support services that are not required by any group that
it supports. 7.1.4. M-INITIALISE Parameters The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service. The parameters for the M-INITIALISE service are defined in [11] and summarized in Table 4. +-------------------+-----------+-----------+ | Parameter Name | Req/Ind | Rsp/Conf | +-------------------+-----------+-----------+ | Functional Units | Mandatory | Mandatory | | User Information | Optional | Optional | | Access Control | Optional | Optional | +-------------------+-----------+-----------+ Table 4. M-INITIALISE Parameters Notice that the further agreement has been made that the Functional Units parameter is mandatory at all times. The M-INITIALISE parameters are conveyed as ACSE user information in the ACSE request PDU. 7.1.4.1. Functional Units The exchange of functional units between the initiating CMISE- service-user and the responding CMISE-service-user is required. This allows the CMIS-service-users to inform each other which functional units are supported. CMIP [12] defines a 21-bit BIT STRING to communicate which functional units are supported. A functional unit is supported if the corresponding bit in this bit string is one. The correspondence between functional units and functional unit groups is given in Table 5. The left column gives the functional unit corresponding to a particular bit position. The numbers along the top of the table indicate the functional unit group (the numbers of the functional unit groups are given in Table 3). The various columns indicate the value of each bit for a particular functional unit group.
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|Functional Unit | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10|
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|conf. event report invoker(0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|conf. event report perf.(1) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|event report invoker(2) | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|event report performer(3) | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get invoker(4) | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get performer(5) | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|confirmed set invoker(6) | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed set performer(7) | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
|set invoker(8) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|set performer(9) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed action invoker(10) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|confirmed action performer(11)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|action invoker(12) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|action performer(13) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|confirmed create invoker(14) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed create performer(15)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed delete invoker(16) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed delete performer(17)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|multiple reply(18) | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
|multiple object selection(19) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
|extended service(20) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
| | M | A | M | A | M | A | M | A | M | A |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
1 = supported, 0 = not supported, M = manager, A = agent
Table 5. Functional Unit Group Values
The "negotiation" using functional units proceeds as follows. The
initiating CMISE-service-user (manager or agent) sends the functional
units representing the functional unit group to which it belongs.
The responding CMISE-service-user sends the functional units
representing the functional unit group to which it belongs. (If an
application process belongs to both a manager and an agent functional
unit group, then both functional unit groups are indicated using the
same functional unit bit string.) If the functional unit groups
supported by the two application entities do not allow meaningful
communication, then either entity may refuse the association.
Meaningful communication is defined as the ability of the entity to
invoke or perform at least one CMIS operation supported by the other
entity (i.e., some "complementary" set of functional units exists).
After an association has been established, a system must provide the
proper response for functional units that it has indicated it can
support and should gracefully refuse other requests in accordance
with the protocol. 7.1.4.2. User Information The User Information parameter is optional. No entity is required to send this parameter, but all entities are expected to tolerate receipt of it. One possible use of the User Information parameter is to convey information describing MIB extensions supported by the manager or agent. This can be viewed as a further way of refining the application context. The mechanism for doing this is not defined at this time. 7.1.4.3. Access Control The CMIS M-INITIALISE Access Control parameter is optional. Access control is supported on a per association basis using ACSE. It is recommended (but not required) that the access control parameter be used for each A-ASSOCIATE request (via M-INITIALISE). Access control is also possible on a per request basis with the CMIS Access Control parameter. This parameter might be used to implement security similar to the community access rights mechanism provided by SNMP [4]. It is expected that the Access Control parameter will be used to implement the standard TCP/IP authentication mechanism once this has been defined. 7.2. Supporting Services The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of ACSE. The following ACSE services are required: A-ASSOCIATE, A- RELEASE, A-ABORT, and A-P-ABORT. The rest of the CMIP protocol uses the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE. 7.3. CMIP Agreements The following sections contain specific CMIP agreements in addition to those specified in the CMIP standard [12]. 7.3.1. Invoke Identifier It is required that there be a unique invoke identifier (present in the ROSE PDU) for successive invocations on the same association. The invoke identifier is provided by the invoking CMISE-service-user. Invoke identifiers should increase monotonically during the lifetime of an association. Semantically, the invoke identifier is a Counter as defined in [2]. Unique identifiers will allow the detection of
lost and duplicate requests. 7.3.2. Object Class The object class field of all CMIP PDUs shall be limited to the "globalForm" choice: ObjectClass ::= CHOICE { globalForm [0] IMPLICIT OBJECT IDENTIFIER } 7.3.3. Object Instance The object instance field of all CMIP PDUs is limited to the "distinguishedName" choice: ObjectInstance ::= CHOICE { distinguishedName [2] IMPLICIT DistinguishedName } The definition for DistinguishedName is imported from CCITT X.500 and ISO DIS 9594-2 [26]: DistinguishedName ::= RDNSequence RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeValueAssertion The definition for AttributeValueAssertion is contained in CMIP [12]: AttributeValueAssertion ::= SEQUENCE { AttributeId, AttributeValue } AttributeId ::= CHOICE { globalId [0] IMPLICIT OBJECT IDENTIFIER localId [1] IMPLICIT INTEGER } AttributeValue ::= ANY DEFINED BY attributeId Those attributes to be used as the distinguished attributes of a managed object are defined at the time of registration of the object class and are identified in the NAMES clause of the OBJECT-CLASS macro.
When there is no instance information to convey about a managed object, then the following "empty" object instance shall be used: The "distinguishedName" choice of ObjectInstance shall be an RDNSequence consisting of a SEQUENCE of one RelativeDistinguishedName. That RelativeDistinguishedName shall be an empty SET of AttributeValueAssertions. 7.3.4. Access Control The access control parameter is optional. The receipt of this parameter must be tolerated (i.e., gracefully accepted), but a receiving entity is free to ignore this information. The Access Control field is defined in [12] as EXTERNAL. Until a more sophisticated access control mechanism is defined, simple authentication can be accomplished by using an unencrypted password in the access control field. The definition of this EXTERNAL is the same as that for the ACSE Access Control field (section 8.3.2). 7.3.5. Synchronization Support for "best effort" synchronization is required. Atomic synchronization may also be supported, but is not required. 7.3.6. Scope Scoping is supported if the multiple object selection functional unit is selected. If scoping is supported, all values of the scope field shall be supported. 7.3.7. Filter Filtering is supported if the multiple object selection functional unit is selected. If filtering is supported, it is not required that all features of filtering be supported. The following are the minimal filtering requirements for any system that supports filtering. In the CMIP field CMISFilter, at least two instances of the binary operators ("and," "or") must be supported. Support for additional instances of these operators is not required. Double "not" need not be supported. In FilterItem, the arithmetic operations ("equality", "greaterOrEqual," "lessOrEqual") must be supported. The "present" choice of FilterItem must also be supported. It is not required to support string operations (namely, the "substrings" choice of the FilterItem type). Thus, the minimal requirements for filtering yield this restricted definition of FilterItem:
FilterItem ::=
CHOICE {
equality [0] AttributeValueAssertion,
greaterOrEqual [2] AttributeValueAssertion,
lessOrEqual [3] AttributeValueAssertion,
present [4] AttributeID
}
7.3.8. Attribute Identifier
Both choices for the CMIP AttributeId field are allowed:
AttributeId ::=
CHOICE {
globalId [0] IMPLICIT OBJECT IDENTIFIER,
localId [1] IMPLICIT INTEGER
}
The "globalId" form of AttributeId is required if scoping is used
(i.e., the value of the scope field is other than "baseObject").
7.3.9. Event Type Identifier
Both choices for the CMIP EventTypeId field are allowed:
EventTypeId ::=
CHOICE {
globalId [6] IMPLICIT OBJECT IDENTIFIER,
localId [7] IMPLICIT INTEGER
}
7.3.10. Action Type Identifier
Both choices for the CMIP ActionTypeId field are allowed:
ActionTypeId ::=
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 RFC 1085 [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.
(page 48 continued on part 3)
