1 Fascicle VIII.4 - Rec. X.211 Fascicle VIII.4 - Rec. X.211 1 Recommendation X.211 Fascicle VIII.4 – Rec. X.211 PHYSICAL SERVICE DEFINITION OF OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS1 (Melbourne, 1988) The CCITT considering (a) that Recommendation X.200 defines the Reference Model of Open Systems Interconnection (OSI) for CCITT Applications; (b) that Recommendation X.210 defines the Service conventions for describing the Services of the layers of the OSI Reference Model; Unanimously recommends that this Recommendation provides the specification for the functions of the Physical Layer Service for operation in the Open Systems Interconnection environment using various transmission modes, topologies, and media. CONTENTS 0 Introduction 1 Scope and Field of Application 2 References 3 Definitions 4 Abbreviations 5 Conventions 6 Overview and General Characteristics 7 Features of the Physical Service 8 Classes of Physical Service 9 Model of the Physical Service 10 Quality of Physical Service 11 Sequence of Primitives 12 Connection Activation Phase 13 Connection Deactivation Phase 14 Data Transfer Phase 0 Introduction 0.1 About this Recommendation This Recommendation is one of a set of Recommendations produced to facilitate the interconnection of information processing systems. It is related to other Recommendations in the set as defined by Recommendation X.200. Reference Model of Open Systems Interconnection for CCITT Applications. The Reference Model of Open System Interconnection (OSI) subdivides the area of standardization for interconnection into a series of layers of specification, each of manageable size. This Recommendation defines the Service provided by the Physical Layer to the Data Link Layer at the boundary between the Physical and Data Link layers of the OSI Reference Model. It provides for the designers of Data Link Protocols a definition of the Physical Service existing to support the Data Link Protocols and for the designers of Physical Protocols a definition of the Services to be made available through the action of the Physical Protocol over the underlying physical media, which are external to the OSI Physical Layer. The relationship of the Physical Layer with the Data Link Layer is illustrated in Figure 1/X.211. Figure 1/X.211 = 7 cm 1 Scope and field of application This Recommendtion defines the OSI Physical Service in terms of: a)the privimitive actions and events, of the Service; b)the parameters associated with each primitive and action and event, and the form which they take; c)the interrelationship between, and the valid sequences of, these actions and events. The principal objective of this Recommendation is to specify the characteristics of a conceptual Physical Service and thus supplement the OSI Reference Model in guiding the development of Physical protocols. This Recommendation does not specify individual implementations or products nor does it constrain the implementation of entities and interfaces within an information processing system. There is no conformance of equipment to this Physical Service Definition Recommendation. Instead, conformance is achieved through implementation of conforming OSI Physical protocols that fulfil the Physical Service defined in this Recommendation. 2 References 1) Recommendation X.200 – Reference Model of Open Systems Interconnection of CCITT Applications (see also ISO 7498). 2) Recommendation X.210 – Layer Service Definition Conventions of Open Systems Interconnection for CCITT Applications (see also ISO/TR 8509) 3 Definitions 3.1 Reference Model Definitions This Recommendation is based on the concepts developed in the OSI Reference Model, Recommendation X.200, and makes use of the following terms defined in that Recommendation: a)Data circuit b)Physical connection c)Physical Layer d)Physical media e)Physical Service f)Physical Service access point g)Physical Service data unit 3.2 Service Conventions Definition This Recommendation also makes use of the following terms defined in Recommendation X.210, OSI Service Conventions, as they apply to the Physical Layer: a)Physical Service user b)Physical Service provider c)primitive d)request e)indication 4 Abbreviations OSI Open Systems Interconnection Ph Physical PhC Physical connection PhL Physical Layer PhS Physical Service PhSAPPhysical Service access point PhSDUPhysical Service data unit PhPDUPhysical Protocol data unit QOS Quality of Service 5 Conventions 5.1 General Conventions This Recommendation uses the descriptive conventions given in Recommendation X.210. OSI Service Conventions. The layer service model, service primitive, and time-sequence diagrams taken from those conventions are entirely abstract descriptions; they do not represent a specification for implementation. 5.2 Parameters Service primitives, used to represent PhS-user/provider interactions (refer to Recommenation X.210) may convey parameters that indicate information available in the user/provider interaction. The parameters, which apply to each group of Physical Service primitives, are set out in tables in Sections 11 to 14. The tables also indicate the association of which parameters can be carried by each respective primitive. Some entries are further qualified by items in brackets. These may be: a)an indication that the parameter is conditional in some way: (C) indicates that the parameter is not present on the primitive for every connection; the parameter definition describes the conditions under which the parameter is present or absent; b)a parameter specific constraint: (=) indicates that the value supplied in an indication primitive is always identical to that supplied in a previous request primitive issued at the peer service access point; c)indication that some note applies to the entry: (note x) indicates that the referenced note contains additional information pertaining to the parameter and its use. In any particular interface, not all parameters used will be explicitly stated. Some may be implicitly associated with the PhSAP at which the primitive is issued. 5.3 PhC Endpoint Identification Convention If at a PhSAP there is more than one PhC, and distinction among then is needed by the PhS user, PhC endpoint identification must be provided. All primitives issued at such a PhSAP would be required to use this mechanism to identify PhCs. Such an implicit identification is not described as a parameter of the service primitives in this Physical Service Definition. When the PhC traverses relays, which are controlled through a separate PhC, an implicit identification mechanism must also provide for identification of these dependencies. 6 Overview and general characteristics The Physical Service provides for the transparent transfer of data between PhS users. It makes invisible to the PhS users the way in which supporting communications resources are utilised to achieve this transfer. Service classes are defined to categorize the distinctions that are visible to the PhS user. The PhS provides for a PhC between PhS users. Since connections cannot be established through the protocol at the Physical Layer but rather are configured when the service is created, the PhC, which is a logical concept, nevertheless must relate directly to the real physical media paths provided to the Physical Layer. For this reason: a)there is no distinction between connection-mode and connectionless-mode at the Physical Layer. The service is independent of whether the higher layers operate in connection-mode or connectionless-mode; b)each PhC is identified within the Physical Layer; c)a PhC can only relate to a particular PhSAP (i.e., a PhC implies a specific source PhSAP and a specific destination PhSAP or group of PhSAPs if a multi-endpoint connection). The PhC may traverse Physical Layer relay, or intermediate systems when several physical media are used in tandem. Such relaying may be controlled through a management function exercised over a separate, but related PhC, or may be controlled from the Network Layer, as specified in Recommendation X.200, § 7.5.4.1 for interconnection of data circuits. The Physical Layer does not make any routing decisions. Intermediate systems may also be used for mapping different Physical Layer protocols associated with a PhC. Quality of Service provided by the Physical Service is predefined, in accordance with the class of service, though it may optionally be varied through management control of the configuration. Actual data transmission takes place over the physical media. The mechanical, electromagnetic, and other media dependent characteristics of the physical media are defined at the boundary (interface) between the Physical Layer and the physical media. Definitions of these characteristics are found in other CCITT Recommendations and International Standards. 7 Features of the Physical Service 7.1 The Physical Service offers the following features to a PhS user: a)the means to activate a PhC with another PhS user for the purpose of exchanging PhSDUs. More than one PhC may exist between the same pair of PhS users. The PhC Activate Service is optional and need not apply for duplex or simplex transmission (i.e. continuous Data Transfer Phase); b)the means of transferring PhSDUs on a PhC. A PhSDU consists of one bit or a string of bits. PhSDUs are transferred in PhPDUs transparently over a PhC without change to the content (within the Quality of Service) or constraint on their data values. PhSDUs are delivered in the same order in which they are submitted; c)the means to identify, when necessary, individual PhCs at the PhSAPs. Note that the parameters to identify a particular PhC within the PhSAP are implicit (see § 5.3); d)the means for unconditional, and therefore possibly, destructive deactivation of a PhC by either the PhS user or by the PhS provider. The PhC Deactivate Service is optional and need not apply for duplex or simplex transmission (i.e. continuous Data Transfer Phase). 7.2 Other aspects of the Physical Service include: a)the transfer of PhSDUs may be either duplex (two-way simultaneous), half-duplex (two-way alternate) or simplex (one way); either point-to-point or multi-endpoint; and either synchronous or asynchronous as appropriate (see § 8); b)the data signalling rate on the physical media may not correspond with the PhSDU throughput rate due to the inclusion of Physical Layer protocol control information, multiplexing function, encoding mechanisms, or other transmission control functions; c)PhSDU synchronization is provided by the Physical Service. This includes bit synchronization. Other delimiting may be available, which is a veritable feature; d)PhC endpoint identifiers are not globally known. In the case of multiplexing, they will be conveyed implicitly via the Physical Layer protocol; e)fault condition notification to the PhS user, beyond conveying a PhC deactivation indication, is for further study. 8 Classes of Physical Services Distinctions of Physical Services are necessary to identify features that relate to the requirements of the service as seen by the Data Link Layer. These distinctions are: a)Type of transmission - synchronous and asynchronous. b)Mode of operation - duplex, half-duplex, and simplex. Note - While these modes describe the operation at the Physical Layer Service boundary between the Physical Layer and the Data Link Layer, they do not necessarily imply the specific mode of operation of the Physical Layer Entity and the interface between the Physical Layer and the underlying physical media. This applies to operations associated with specific Physical Service Provider implementations, such as collision detection and multiplexing, which may map onto certain service primitives (for example, Activation and Deactivation) but are otherwise transparent to the Physical Service User. 9 Model of the Physical Service 9.1 Model of the Layer Service This Recommendation uses the abstract model for a layer service defined in § 4 of Recommendation X.210, OSI Service Conventions. The model defines the interactions between the PhS users and the PhS provider that take place at PhSAPs. Information is passed between the PhS user and the PhS provider by service primitives, which may convey parameters. The description of the model is applicable to point-to-point PhCs (linking two PhSAPs). The extension of the model for multi-endpoint PhCs is for further study. 9.2 Model of a physical connection The operation of a PhC is modeled in the abstract by a pair of bit streams linking the two PhSAPs. There is one bit stream for each direction of transmission (see Figure 2/X.211). Each bit stream conveys Physical Protocol Data Units (PhPDUs). Bits within each bit stream are delivered in the same order in which they were submitted. 9.3 Model of a relayed point-to-point PhC where the relay is controlled within the PhS Provider The operation of a PhC is modeled exactly as described in § 9.2 except for the interposition of the relay within the data circuit to support tandem physical media (see Figure 3/X.211). 9.4 Model of a relayed point-to-point PhC where the relay is controlled from the Network Layer The operation of each of the relay-controlling PhCs can be accomplished by the Network Layer protocol control information being conveyed either via the same PhC (in-band signalling), or via a separate PhC (out-of-band signalling), see Figure 4/X.211. Physical Layer relay systems do not complete the end-to-end PhC until Network Layer control actions are completed among the Network Layer entities en route. Deactivation may be accomplished through either Network layer protocol or management actions. Figure 2/X.211 = 7 cm Figure 3/X.211 = 7 cm Figure 4/X.211 = 10 cm 10 Quality of Physical Service The term “Quality of Service” (QOS) refers to certain characteristics of a PhC as observed between the PhC endpoints. QOS describes aspects of a PhC that are attributable solely to the PhS provider: it can only be properly determined in the absence of PhS user behaviour (which is beyond the control of the PhS provider) that specifically constrains or impairs the performance of the Physical Service. The PhS users have knowledge of the relevant QOS of the PhC. This is true even in the case of a PhC scanning several physical circuits. The Quality of Service of a PhC is dependent on the physical media of interconnection. It may be characterized by: a)service availability; b)error rate, where errors may arise from alteration, loss, creation, and other causes; c)throughput; d)transit delay; e)protection (e.g. encryption). QOS is described in terms of QOS parameters. These parameters are selected and determined by methods other than Physical Service primitives, although they may be determined in some cases through layer management primitives. There is no guarantee that the originally agreed upon QOS values will be maintained throughout the lifetime of the PhC. The PhS users should be aware that a change in QOS is not explicitly signalled in the Physical Service, although in some cases it may be signalled through layer management primitives. 11 Sequence of primitives This section defines the constraints on the sequences in which the primitives defined in §§ 12-14 may occur. The constraints determine the order in which primitives occur, but do not fully specify when they may occur. Table 1/X.211 is a summary of the PhS primitives and their parameters, and defines the phases in which they occur (Activation, Data Transfer, and Deactivation). TABLE 1/X.211 Summary of physical service primitives and parameters Phase Service Primitive Parameters PhC activation Ph-ACTIVATE (Note 1) PhC activation request (Note 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . Ph-ACTIVATE indication Ph-DATA request Data transfer Data transfer . . . . . . . . . PhS-User data . . . . . . . . . . . . . . . . . . Ph-DATA indication PhC Ph-DEACTIVATE deactivation PhC request (Note 3) (Note 1) deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . Ph-DEACTIVATE indication Note 1 - The PhC activation and the PhC deactivation services are optional and need not apply for duplex or simplex transmission. Note 2 - Parameters associated with the classes of service (see Section 8) are for further study. Note 3 - Parameters associated with PhC deactivation are for further study. 11.1 Relation of primitives at the two PhC endpoints A primitive issued at one PhC endpoint will, in general, have consequences at the other PhC endpoint. The relations of primitives of each type to primitives at the other PhC endpoint are defined in the appropriate subsection in §§ 12-14; these relations are summarized in the diagrams in Figure 5/X.211. Additional sequences and relationships are for further study. 11.2 Sequence of primitives at one PhC endpoint The recognized sequence of primitives at PhC endpoints is defined in the composite state transition diagram, Figure 6/X.211. Specific primitive sequences that apply to individual modes of operations and topologies are shown in Figures 6a/X.211 through 6i)/X.211. Figure 5/X.211 =21 cm PAGE PLEINE Figure 6/X.211 = 13 cm Figure 6a/X.211 = 7,5 cm Figure 6b/X.211 = 8cm Figure 6c/X.211 = 8cm Figure 6d/X.211 = 10,5 cm Figure 6e/X.211 = 4cm Figure 6f/X.211 = 4cm Figure 6g/X.211 = 4 cm Figure 6h/X.211 = 8 cm Figure 6i/X.211 = 7,5 cm 12 PhC activation phase 12.1 Function The PhC activation service primitives are used for activating directions of PhPDU transmission. They are required for half-duplex and are optional for duplex and simplex. The Ph-ACTIVATE request primitive requests activation of the PhC. Each direction of transmission is activated independently for half-duplex operation, and both directions of transmission are activated for duplex operation. For half-duplex and simplex operation, the Ph-ACTIVATE request primitive activates the outgoing direction of transmission, and the Ph-ACTIVATE indication primitive indicates activation of the incoming direction of transmission. During half-duplex operation, a Ph-ACTIVATE request cannot be issued by the PhS user after receipt of the Ph-ACTIVATE indication and before the receipt of a Ph-DEACTIVATE indication primitive. 12.2 Types of primitives and parameters The PhC activation service involves two primitives as shown in Table 2/X.211. The parameters in the table are for further study. TABLE 2/X.211 Physical service activate primitives and parameters Primitive Ph-ACTIVATE request Ph-ACTIVATE indication Parameter (Note) Note - Parameters associated with the classes of service (see Section 8) are for further study. 12.3 Sequence of primitives The sequence of primitives in a successful activation of a direction of transmission is defined by the time sequence diagram in Figure 7/X.211. 13 PhC deactivation phase 13.1 Function The PhC deactivation service primitives are used for deactivating direction of PhPDU transmission. They are required for half-duplex and are optional for duplex and simplex. The Ph- DEACTIVATE request primitive requests deactivation of the PhC. Each direction of transmission is deactivated independently for half- duplex operation, and both directions of transmission are deactivated for duplex operation. For half-duplex and simplex operation, the Ph-DEACTIVATE request primitive deactivates the outgoing direction of transmission, and the Ph-DEACTIVATE indication primitive indicates deactivation of the incoming direction of transmission. During half-duplex operation, a Ph- ACTIVATE request primitive can be issued by a PhS user after receipt of the Ph-DEACTIVATE indication primitive. 13.2 Types of primitives and parameters The PhC deactivation service involves two primitives as shown in Table 3/X.211. Figure 7/X.211 = 13,5 cm TABLE 3/X.211 Physical service deactivate primitives and parameters Primitive Ph-DEACTIVATE Ph-DEACTIVATE request indication Parameter (Note) Note - The need for deactivation parameters, e.g., Originator, are for further study. The Originator parameter indicates the source of the PhC deactivation. Its value indicates whether PhS user, PhS provider, or unknown caused the action. 13.3 Sequence of primitives The sequence of primitives for PhC deactivation are expressed in the time sequence diagrams in Figure 8/X.211. Figure 8/X.211 = 20 cm 14 Data transfer phase 14.1 Function The data transfer service primitives provide for an exchange of user data called Physical Service Data Units (PhSDUs). The Physical Service preserves the sequence of the PhSDUs. 14.2 Types of primitives and parameters Table 4/X.211 indicates the types of primitives and the parameters needed for data transfer. TABLE 4/X.211 Data transfer primitives and parameters Primitive Ph-DATA request Ph-DATA indication Parameter User data X X(=) The User Data parameter conveys PhSDUs for transmission between the PhS users. The size of the PhSDU is a PhS provider option. The PhS user has a prior knowledge of the PhSDU size value. 14.3 Sequence of primitives The operation of the Physical Service in transferring PhSDUs can be modeled as a pair of bit streams within the PhS provider (see § 9). The Physical Layer serves to pass a transparent bit stream (PhSDUs) continuously. This requires that the Ph-DATA primitives are present, as necessary, throughout the Data Transfer Phase. Immediately upon receipt of a Ph-ACTIVATE indication primitive, an incoming user data bit stream (PhSDUs) is available to the PhS user. Upon issuance of a Ph-ACTIVATE request primitive, an outgoing user data bit stream (PhSDUs) is assumed to be available to the PhS user. The sequence of primitives in a successful data transfer is defined in the time sequence diagram in Figure 9/X.211. Figure 9/X.211 = 3,5 cm The sequence of primitives in Figure 9/X.211 may remain uncompleted if an Ph-DEACTIVATE primitive occurs. _______________________________ 1 Recommendation X.211 and ISO/IEC 10022 [Information Processing Systems - Open Systems Interconnection - Physical Layer Service Definition] were developed in close collaboration and are technically aligned.