GB/T 15126-1994 Information processing system data communication network service definition
Some standard content:
National Standard of the People's Republic of China
Informatlon processing systemsDatacommunlcatfons-Network service definitionGB/T15126-94
ISO 834B--1987
This standard is equivalent to the international standard ISO) 8348-1987 "Information processing systemDatacommunlcatfons-Network service definition"0 Introduction
This standard is one of the national standards formulated for the interconnection of computer systems. It is related to other standards in the group of standards defined by the Open Systems Interconnection (OSI) basic reference model. The (OSI) basic reference model decomposes the field of interconnection standardization into a series of hierarchical specifications, each of which is manageable in size.
This standard defines the network layer's provision of services to the transport layer at the boundary of the network layer and the transport layer of the reference model. It provides the transport layer protocol designer with the definition of existing network services to support the transport layer protocol, and provides the network protocol designer with the definition of available services. This service is implemented based on the actions of the network protocol of the lower layer service. This relationship is shown in Figure 1. Transport protocol -
Network protocol
Transport attribute
Network layer
Use service
Network service
Provide service
Figure 1 The relationship between this standard and the protocols specified in other OSI standards The term "network" refers to the network layer of the OSI reference model, which should To distinguish it from the "network" in the commonly used communication network, in order to facilitate this distinction, "subnet" is used to represent a group of physical devices that are collectively called a "network" (see GB9387). Subnets can be public networks or private networks. In the case of public networks, their properties are determined by ISO 11593 for circuit switching networks or GB11595 for packet switching networks and other corresponding CCITT recommendations. In the entire set of OSI standards, the term "service" refers to the abstract capabilities provided by a layer of the OSI reference model to its higher layer. Therefore, the "network service" defined in this standard A service is a conceptual service in the network architecture and has nothing to do with the management department. Note: It is important to distinguish the use of the term "service" in the entire set of standards from its use in other places to describe services provided by an organization (for example, services provided by the General Administration of Customs under other constructions of CCITT). Any particular subnet may or may not support OSI network services. OSI network services can be provided by a combination of one or more subnets and optional additional functions between or outside these subnets. 1 Subject matter and scope of application
This standard defines OSI network services in terms of the following aspects: a. primitive actions and events of the service;
Approved by the State Administration of Technical Supervision on July 16, 1994 and implemented on March 1, 1995
GB/T 15126-94
b. Parameters associated with each primitive action and event and the form they take; c. The relationship between these primitive actions and events and their valid sequence. The main objectives of this standard are:
to define the characteristics of conceptual network services, thereby complementing the reference model to guide the development of network layer protocols, b. to encourage convergence in the functionality provided by network providers; c. to provide a basis for upgrading existing heterogeneous subnetworks to common network-independent network services so that they can be connected to provide global communications (such connection may involve optional additional functions not defined in this standard). Defining network service carriers is an important part of network service standards: d. to provide a basis for the development and implementation of subnetwork-independent transport layer protocols, so as to free it from the diversity of underlying public and private networks and their special interface requirements. This standard does not specify specific implementations and products, nor does it restrict the implementation of system internal entities and interfaces. There is no equipment conformance issue for this standard. Conformance is achieved by implementations that follow the COSI network protocol. (SI[network protocols meet the network services defined in this standard. 2 Reference standards
GB9387 Information processing systems Open Systems Interconnection, Basic Reference Model (ISO) 7498) Note: See also the Open Systems Interconnection Reference Model of CCITT Recommendation X.200CCTTT Application. GB12500 Information Processing System Open System Interconnection Connection-Oriented Transport Protocol Specification Note: See also (CITT Recommendation X.224 CCITT Application Open System Interconnection Transport Protocol Specification. GB/T15129 Information Processing System Open System Connection Service Agreement (ISO/TR8509) Note: See also CCITT Recommendation X.210 OSI Layer Service Definition Agreement. CCITT Recommendation X.213 CCITT Application Open Interconnection Network Service Definition Part I Overview
3 Definitions
Note: The definitions included in this chapter use the abbreviations extended from Chapter 4. 3.1 Definitions of the Reference Model
This standard is based on the concepts established in the >SI Reference Model (GB9387) and uses the following terms defined in the GB9387 standard:
Accelerated Network Service Data Unit cxpcditedNetwark-Service-dala-unit, Network Connection Netwark-Cannection;
Network Layer Netwark L.ayer;
Network Service Network Service;
Network-Service-access-pointNetwork-Service-access-point addressNetwork-Service-data-unit: Subnetwork.
3.2 Definition of service agreement
This standard also uses the following terms defined in GB/T15129 and applicable to the network layer:.
Network service userNetwork Service providerNetwork Service providerPrimitive:
request;
e. indication
f. responseresponse;
g. confirmation.
3. 3 Definition of network service
The following definitions apply to this standard.
3. 3. 1 Calling NS userCalling NS uxer initiates a request to establish an NC user.
3.3.2 Called NS user CalledNSuset
GB/T 15126---94
The user with whom the calling user wishes to establish an NC. Note: The calling NS user and the called NS user are defined for a single NC. An NS user can be both the calling NS user and the called NS user at the same time. 3.3.3 Family address: An address that identifies a group of NSAPs rather than an address that identifies a specific NSAP. 4 Abbreviations
COR Confirmation of receipt
Accelerated network service data unit
N network
NC Network connection
NL, network layer
NS Network service
NSAP Network service access point
Network service data unit
CS1 Open Systems Interconnection
QOS Quality of service domain
5 Conventions
5. 1. General definitions
This standard uses the descriptive conventions given in GB/T 15129. The hierarchical service model derived from these conventions, the service primitives and the sequence diagrams are completely abstract descriptions. They do not represent the technical specifications of the implementation.
5.2 Parameters
The service primitives used to represent the service user/service provider interaction (see GB/T 15129) carry some parameters that indicate the information available in the user/provider interaction. The parameters applicable to each level of the network service primitive are listed in the tables in Chapters 12 to 14. Each "×" in the table indicates that the primitive in its column can carry the parameters in its row.
Some entries are further qualified by the items in brackets. These may be:. An indication that the parameter is conditional in some respect; (C) - For each NC, it indicates that the parameter may not exist in that primitive. The definition of the parameter describes the conditions under which the parameter exists.
b.Parameter-specific restrictions:
Indicates that the value provided in the indication or confirmation primitive is always the same as the value provided in the corresponding request or response primitive issued at the peer NSAP.
c. Indication of a certain note applicable to this entry: (Note ×) - indicates that the parameter includes additional information related to the parameter and its use. GB/T 15126-94
In any particular interface, it is not necessary to explicitly indicate all parameters, and some parameters may be implicitly related to the NSAP that issued the primitive. 5.3 NC Endpoint Identification Conventions
If an NS user needs to distinguish between several NCs on the same NSAP, a local NC endpoint identification mechanism must be provided. All primitives issued on such an NSAP need to use this mechanism to identify the NC. This implicit identification is not described as a parameter of the service primitive in this standard.
Note: This implicit NC endpoint identification must not be confused with the address parameter of the N-CONNECT primitive (see clause 12.2). 6. Description and General Characteristics
Network services provide transparent transmission of data (i.e., NS user data) between NS users. The method by which this transmission is achieved using resources that support the communication is invisible to these NS users. In particular, network services provide the following characteristics: a. Independence from the underlying transmission media - Network services relieve VS users from having to be concerned with how the various subnets provide network services. Network services relieve NS users from having to understand differences in the transmission of data over heterogeneous subnets, only differences in the quality of service. b. End-to-end transmission - Network services provide transmission of VS user data between NS users in end systems. All routing and relay functions are performed by the NS provider, including the use of similar transmission resources in a relay or parallel manner. C. Transparency of transmitted information - Network services provide transparent transmission of an integral number of octets of NS user data and/or control information. It does not restrict the content, format or encoding of the information, nor does it require interpretation of its structure or meaning. d. Choice of quality of service - Network services provide NS users with a means to request and negotiate the quality of service for the transmission of NS user data. The quality of service is specified by QOS parameters that represent characteristics such as throughput, transit delay, accuracy and reliability.
e: NS User Addressing - The network service uses an addressing system (VSAP addressing) that allows NS users to address each other in an unambiguous manner. 7 Network Service Characteristics
The network service provides the following characteristics between NS users: a. Provides means to establish NCs with an NS user in order to transmit NS user data in the form of NSDUs. More than one NC can exist between the same pair of NS users
b. Agrees on a certain QOS associated with each NC between the two NS users and the NS provider. C. Provides means to transmit NSDUs in sequence on an NC. The transmission of NSDUs consisting of an integer number of octets is transparent, that is, the network service maintains the inverse boundary and content of the NSDU unchanged and the network service does not impose any restrictions on the content of the NSDU: d. The receiving NS user can perform flow control on the rate at which the sending NS user sends NSDUs. e.
In some cases, provide means for the in-sequence transmission of accelerated NSDUs (see clause 8). Accelerated NSDUs are limited in length. Their transmission is subject to flow control different from that of regular data passing through the NSAP. f.
Provide means for the NC to return to a certain state and for the activities of two NS users to be synchronized through the use of the reset service.
g. In some cases, provide means for the NS users to confirm the receipt of NSTUs (see clause 8). b. An unconditional, and therefore potentially destructive, release of the NC initiated by one of the NS users or by the NS provider. 8 Network Service Categories
Different categories of network services are not specified, however, two services, network layer reception confirmation and accelerated data delivery, are options for NS providers.
Services requested by the NS provider are optional, and the NS provider may choose to provide or not provide services for a particular NS. In the case where the NS provider does not provide the optional service, the service will not be available in the network service. If the provider offers the options of receipt confirmation or accelerated data transfer, it shall be provided in accordance with the provisions of this standard (see clauses 14.1 to 14.3). GB/T 15126-94
All other network services are mandatory in the network service. For mandatory services, each NS provider must provide them and they are always available.
9 Network service model
9.1 Network layer service model
This standard uses the layer service abstract model defined in Chapter 4 of ISO/TR8509. The model defines the interaction between NS users and NS providers occurring on two NSAPs. Between NS users and NS providers, information is passed through service primitives that can carry parameters.
There are two types of QSI network services:
Connection-mode services (defined in Part II of this standard). Connection-mode services are characterized by characteristics a to h given in Chapter 7 above.
b. Connectionless-mode services (see the definition in Supplement 1 of this standard). When referring to a network service, an NS user or NS provider shall indicate what type of network service it expects to use or provide. 9.2 Network Connection Model
Between the two endpoints of an NC, there is a flow control function that relates the behavior of the NS user at one end receiving NS user data to the capabilities of the NS user at the other end sending NS user data. As a means of specifying this flow control behavior and its relationship to other capabilities provided by the network service, the NC queue model described below may be used. The discussion of this NC queue model is intended only to aid in understanding the end-to-end service characteristics perceived by the network service user and is not intended to replace a precise formal description of the network service, nor is it intended to be a complete specification of all allowed NS primitive sequences (the allowed primitive sequences are specified in clause 11, see also the note below). In addition, this model does not attempt to describe all functions or operations of network layer entities (including relay entities) used to provide network services, nor does it attempt to imply or restrict the implementation of network services. In interpreting this standard, the descriptions of clauses 12 to 14 concerning the properties of individual primitives take precedence over the general descriptions in this clause. NOTE In addition to the interactions between the service primitives described in this model, there may be some locally imposed restrictions on the capabilities of the enabled primitives and service procedures that define specific ordering constraints on these primitives. 9.2.1 Concept of the Queuing Model
The queuing model can abstractly represent the operation of a NC by a pair of queues linking two NSAPs. There is a queue for each direction of information flow (see Figure 2).
NS user A
Queue from A to B
Queue from A to B
NS provider
Figure 2 Queuing model for network connections
NS user B
Each queue represents a flow control function in each transmission direction. The ability of an NS user to add objects to a queue depends on the behavior of the NS user who removes objects from the queue and the state of the queue. Objects can enter a queue as a result of the interaction between the two service access points or due to the initiation of the NS provider. It can be assumed that this queue applies to each possible NC. GB/T 15126—94
Objects that may be placed in a queue as a result of interaction at a NSAP (see Chapters 12 to 14) are: connection objects (associated with the N-CONNECT primitive and all their parameters); a.
Normal NS user data octets (associated with the N-DATA primitive); b.
NSDU end indication (associated with the completion of the N-JATA primitive); d.
Expedited NSDU (associated with the N-EXPEDITED-DATA primitive and all their parameters); data acknowledgment objects (associated with the N-DATA-ACKNOWLEDGE primitive); f.
Reset objects (associated with the N-RESET primitive and their parameters); disconnection objects (associated with the N-DISCONNECT primitive and all their parameters). g
Note: The flow control description (see clause 9.2.3) requires less abstraction than the description of the primitive sequence in clauses 11 to 14. Although the primitives defined are indivisible, for the purposes of this description the values associated with the N-DATA primitive can be conceptually separated into a series of NS user data octets.This is followed by an end indication of an NSDU. This does not imply that any specific further segmentation is required in any security interface. Objects that may be placed in the queue initiated by the NS provider (see clauses 12 to 14) are: Reset objects (associated with the N-RESET primitive and all their parameters): Synchronization marker objects (see clause 9.2.4)
C. Disconnect objects (associated with the N-DISCONNECT primitive and all their parameters). Queues are defined as having the following general properties: 1) Queues are empty before a connection object enters them, and the NS provider can return the queue to that state in the event of loss of its contents (see clauses 9.2.4 and 9.2.5).
2) Objects may enter a queue under the control of the NS provider as a result of actions by the originating NS user, and objects may be entered by the NS provider.
3) Objects may be removed from a queue under the control of the receiving NS user.
4) Objects are normally removed from a queue under the control of the NS user in the same order in which they entered (otherwise, see clause 9.2.3).
5) A queue has a finite capacity, but that capacity need not be fixed or deterministic. 9.2.2 Recommendations for NCs
When the NS provider receives the N-CONNECTIequest primitive at one of two NSAPs, and a connection object enters one of the two queues, a pair of queues is associated with the NC between the two NSAPs. From the perspective of one of the two NS users of the NC, the queue remains associated with the NC until a disconnect object (associated with an N-DISCONNECT primitive) enters or is removed from the queue at that NSAP.
If NS user A indicates that it is the NS user that initiated the establishment of the NC (forming a connection object that enters the queue from NS user A to NS user B), no objects other than the disconnect object may enter the queue from A to R until the connection object associated with N-CONNECTconfirm is removed. In the queue from NS user B to NS user A, objects may enter only after the connection object associated with N-CONNECTresponse from NS user B enters. The NC may be released only when a disconnect object is placed in the queue from B to A instead of a connect object.
The nature of the queue in the presence of the NC reflects the agreement between the NS user and the NS provider during the NC establishment process on the quality of service, receipt confirmation and the use of accelerated data transfer services. 9.2.3 Data transfer operations
Flow control on the NC in this queue model is represented by the principle of queue capacity, which allows certain types of objects to join the queue. The conditions that affect the entry of reset and disconnected objects into the queue are described in b below and in 9.2.4 and 9.2.5. The flow control relationships between other types of objects are summarized in Table 1.
Can X be added?
GB/T 15126—94
Table 1 Flow control relationship between objects in the queue model Object X
Normal NS user data octet or NSDU end accelerated NSDU
Data confirmation
Normal NS user data entry
Octet or NSDU end
Accelerated NSDU
+Once there is an object in the queue, the NS provider can process the received object pair, resulting in: data confirmation
Change of order The order of the object pair can be reversed only if and only if the following object has a type that is defined to be able to surpass the previous object. In the same type, ... objects cannot be defined to be able to surpass the previous object. b. Deletion, if and only if any object following the object is defined to be destructive to it, this object can be removed. If necessary, the last object in the queue can be deleted to allow destructive objects to enter. Therefore, destructive objects can always enter the queue. Disconnecting objects can be defined as destructive relative to all other objects. Resetting objects are defined as destructive relative to all other objects except disconnecting and other resetting objects.
The relationship between objects that can be processed according to a and b above is summarized in Table 2. Whether the NS provider performs actions that lead to reordering and deletion depends on the behavior of the NS user and the QOS agreed for the NC. In general, if an NS user does not cause objects to be withdrawn from the queue, the NS provider will perform the actions allowed by type a and type b above after an unspecified time period. Table 2 Ordering relationship between objects in the queue model
Later object x
Octet of regular NS user data
NSDU end
Accelerated NSDU
Data confirmation
Sync mark
Regular NS user
NSDU end of user data Accelerated NSDU
Data confirmation
Octet
AA, indicating that object X is defined to be able to surpass the previous object Y, N/A
DES: indicating that object X is defined as destructive relative to the previous object Y. AA
: indicating that object X is neither destructive relative to object Y nor can it surpass the previous object Y. N/A: indicating that object X will not appear in the position of the subsequent object Y in the existing valid state. Synchronization Mark
9.2.4 Reset Operation
GB/T15126—94
In both queues, the activation of the reset procedure is indicated as follows:. The activation of the reset procedure by the NS provider is indicated by the introduction of a reset object followed by a synchronization mark object in each queue.
b. The reset procedure initiated by the NS user is indicated by adding a reset object to one queue. In this case, the NS provider inserts the reset object followed by the synchronization mark object into the other queue. The reset procedure completed by the NS user sending an N-RESETresponsc will cause the reset object to be inserted into the queue from the responding NS user.
The synchronization mark object cannot be withdrawn from the queue by the NS user. From the NS user's point of view, when the synchronization mark object is the next object in the queue, the queue is suspended. Unless it is destroyed by a disconnection object, the synchronization mark object remains in the queue until the next object following it in the queue is the reset object. The SyncMarker object and the following Reset object are then deleted by the NS provider. Often, associated with the initiation of the Reset procedure are restrictions on sending certain other types of primitives, which may result in restrictions on the entry of elements of certain object types into the queue until the Reset procedure is complete.
9.2.5 NC Release
The insertion of a Disconnection object into a queue, which can occur at any time, indicates the initiation of the NC Release procedure. The Release procedure may be disruptive to other objects in both queues, ultimately resulting in the emptying of the queues and the decoupling of the queues from the NC. The insertion of a Disconnection object may also indicate a rejection of the NC establishment attempt or a failure of the NC establishment. In this case, if the Connection object representing the NCONNECTResponse primitive is deleted by the Disconnection object, then the Disconnection object is also deleted. The Disconnection object is not deleted when it deletes any other object, including the case where it shadows the Connection object representing the N-CONNECTResponse. 10 Quality of Network Service
The term Quality of Service (QOS) refers to certain characteristics of an NC observed between NC endpoints. QOS describes only those aspects of the NC that are relevant to the NS provider. QOS can be properly determined only when NS user behavior (outside the control of the NS provider) does not specifically restrict or impair network service performance. The value of QOS applies to the entire NC. When determined or measured at both ends of the NC, the QOS observed by NS users at both ends of the NC is the same, even if the NC spans several networks, each providing different services. 10.1 Determination of QOS
QOS is described in terms of QOS parameters. Each of these parameter definitions specifies a method for measuring or determining the value of a QOS parameter so that NS primitive events can be referenced where appropriate. Note: ① It is important to distinguish between the term "QOS parameter" and the general term "parameter". The latter is defined in clause 5.2 and used in this standard. "QOS symbol" refers to a to-be-determined aspect or component of the QOS of the NC. As described below, a specific QOS parameter may be related to or unrelated to a parameter defined as part of a network service primitive.
②For accuracy and/or convenience, the definitions and measurement formulas of certain QOS parameters include components attributable to NS users. In this case,To estimate the QOS attributed to the NS data provider, the components related to the NS user must be excluded. ③ The definition of NSQOS parameters in the terminology of providing measurement means should not be understood as the monitoring of QOS or the verification of specified QOS values being or must be performed by the NS provider or NS user.
The QOS-related information exchanged between the NS provider and the NS user is expressed in terms of NSQOS parameters. Information about the QUS requirements of the NS user can be used by the NS provider for purposes such as protocol selection, routing decisions and resource allocation. Information about the available QOS from the NS provider is used by the NS user for purposes such as selecting a QOS improvement mechanism and determining the QOS value to be provided to the higher-level NS user. NSQOS parameters can be divided into the following two categories: a. those parameters whose values are "transferred" by the NS between peer NS users during NC establishment. As part of this transmission, a three-way "negotiation" between peer NS users and NS providers to agree on a specific QOS parameter value may occur; b. those parameters whose values are not "transferred" or "negotiated" between NS users and NS providers. For these QOS parameters, information about some values useful to the NS provider and each NS user can be learned through local means. NS QOS parameters are defined in clauses 10.2.1 to 10.2.12. The group of NSQOS parameters belonging to category 1, as well as the procedures and restrictions applicable to the transmission and negotiation of these QOS parameters, are specified in clause 12.2.7. Once the NC is established, these two types of QOS The agreed values of the parameters are not "renegotiated" at any time, and there is no guarantee that the originally negotiated values will remain unchanged. NS users should be aware that once an NC is established, changes in the NC and QOS are not explicitly announced in the NS.
For the QOS parameters in the second category, the values used for a particular NC are not negotiated or directly carried from NS user to NS user, however, there may be a means by which the NS provider and each NS user know and use one or more of these QOS parameter values as a local matter. Despite the local nature of the specific NS user/NS provider interactions that may occur to exchange QCS parameter information, the characteristics of the NC described by the QOS parameters are still applicable and can be observed on an end-to-end basis for the entire NC. In order to give a full characterization of the nature of the NC, the definition of the entire set of QOS parameters applicable to the NS, including those parameters that fall into the second category, are included in this network service definition. Other aspects related to the second category parameters, such as their availability and use and other QOS topics, such as the relationship to CSI management and the relationship to multi-layer QOS are the subject of other OSIQOS-related specifications. NOTE: For non-negotiated QCS parameters related to the data transfer order of the NC, when specified, the values of such parameters apply to both transfer directions of the NC. 10.2 Definition of QOS parameters
QOS parameters can be classified as:
. The QOS parameters representing the performance of the network service are shown in Table 3. Table 3 Performance classification of QOS parameters
NC establishment
Data transmission
NC establishment delay
Throughput
Transfer delay
NC release delay
Performance criteria
Accuracy/reliability
NC establishment failure probability
(false connection/NC rejection)
Residual error rate (error, duplication/loss)
NC rebound rate
Transmission failure probability
NC release failure probability
QOS parameters representing other performance of the network service are shown in Table 4. Table 4 QOS parameters not related to performancebzxz.net
NC protection
NC priority
Maximum acceptable cost
Note: Some QOS parameters are defined according to the transmission of the original spectrum of the network service. The term "primitive" in clauses 10.2.1 to 10.2.12 refers to the execution of that service primitive on the appropriate NSAP.
10.2.1 NC setup delay
The NC setup delay is the maximum acceptable delay between the N-CONNECTrequest and the corresponding N-CONNECTconnection primitive.
Note that this delay includes the component attributable to the calling NS user. This component is the time between the N-CONNECTindiention primitive and the V-CONNECTresponse primitive. 10.2.2 NC setup failure probability
The NC setup failure probability is the ratio of the total number of NC setup failures to the total number of NC setup attempts in the measurement sample. The failure to establish the requested NC within the specified maximum acceptable time due to NS provider behavior such as connection rejection, NC rejection or excessive delay is defined as NC setup failure. The number of NC establishment attempts that failed due to NS user actions such as errors, NC rejections or excessive delays shall not be included in the calculation of the NC establishment failure probability. 10.2.3 Throughput
For each transmission direction, the throughput is defined as a sequence of at least two successfully transmitted NSDUs presented consecutively to the NS provider. The maximum rate presented to the NS provider is the value that the NS provider can sustain continuously. This rate is not limited by flow control imposed by the receiving NS user.
If such a sequence of n NSDUs is given (where n is greater than or equal to 2), the throughput is defined as the smaller of the following and b.
a. The number of NS user data octets included in the last n-1 NSDUs, divided by the time between the first and last N-DATA request in the sequence;
b. The number of NS user data octets included in the last n-1 NSDUs, divided by the time between the first and last N-DATA indication in the sequence. Successful transmission of the octets in a transmitted NSDU is defined as the delivery of these octets in proper sequence without errors to the intended receiving NS-User before the receiving NS-User releases the NC. Throughput is defined separately for each direction of transmission. Each throughput specification shall specify a desired "target value" and an acceptable minimum value (i.e. "minimum acceptable quality") for the NC (see also clause 12.2.7). 10.2.4 Transit Delay
Transit delay is the time elapsed between an N-DATAIrequest and the corresponding N-DATA indlication. This time value is calculated only for successfully transmitted NSDUs.
Successful transmission of an NSDU is defined as the delivery of an NSDU from the transmitting NS-User to the intended receiving NS-User without errors and in proper sequence before the receiving NS-User releases the NC. The specification of transit delay defines a pair of values: a desired "target value" and an acceptable maximum value (i.e. "minimum acceptable quality") (see also clause 12.2.7). The values specified are average values and shall be based on the length of the NSIU, which is 128 octets. A pair of transit delay values specified for an NC applies to both directions of transmission. That is, the transit delay in each direction is not expected to be worse than the specified value.
If the receiving NS user performs flow control, the transit delay of an individual NSDU may increase. This should be ignored when calculating the average and maximum transit delay values.
10.2.5 Residual Error Rate (RER)
The residual error rate is the ratio of the total number of incorrect, lost and duplicated NSDUs transmitted across the NS boundary in a measurement period to the total number of NSDUs. For a specific pair of NS users, the relationship between these quantities is defined as shown in Figure 3. 10.2.6 Delivery failure probability
NSDU sent
Lost
GB/T 15126—94
NSDU successfully transmitted
NSDL received
Excess NSIL
Incorrect NSD
Total NSDU sentCN
RER - Ne)-Nc)+ N(s)
Figure 3 Components of residual error rate
The delivery failure probability is the ratio of the total number of delivery failures observed during a performance measurement to the total number of delivery samples. A delivery sample is a discrete observation of the performance of the NS provider when transmitting NSIUs between designated transmitting and receiving NS users. A delivery sample begins with the input of a selected NSDU at the boundary of the transmitting NS user and continues until the result of the transmission request for a given number of NSDUs is determined. A delivery sample usually corresponds to the existence period of an NC. A delivery failure is a delivery sample in which the observed performance is worse than the minimum acceptable performance. Delivery failures are identified by comparing the measured values of supported performance parameters with the specified delivery failure thresholds. Two performance parameters supported are throughput, transit delay and residual error rate.
In systems where the network service QOS is reliably monitored by the NS provider, the delivery failure probability can be estimated by the probability that the NS provider invokes N-DISCONNECT during the delivery sampling period. 10.2.7 NC Bounce Rate
On an established NC, the NC Bounce Rate parameter specifies the probability of the following events within a specified time interval:
a. The NS provider invokes NC release (i.e., an N-DISCONNECT indication is sent without a previous N-DISCONNECT request):
b. The NS provider invokes reset (i.e., an NRESET indication is sent without a previous N-RESET request). 10.2.8 NC Release Delay
The NC Release Delay is the maximum acceptable delay between the initiation of an N-DISCONNECT request by an NS user and the successful release of the NC by the peer NS user. The NC Release Delay is usually specified independently for each NS user. The NC Release Delay does not apply when the NC release is initiated by the NS provider.
The NC Release Delay is calculated for a VS user at the beginning of an N-DISCONNECT request initiated by one of the two NS users. A successful release is notified to the NS user that initiated the N-DISCONNECT request via an N-DISCONNECTindication.
10.2.9 NC Release Failure Probability
The NC Release Failure Probability is the ratio of the total number of NC Release failures to the total number of NC Release requests within a measurement sample. The NC Release Failure Probability is usually specified independently for each NS user. For a specific NS user, if the user does not receive the N-DISCONNECT indication within the maximum delay range of NC release specified by the NS user that sent the N-DISCONNECT request (assuming that the previous NS user has not sent the N-DISCONNECT request), this phenomenon is defined as a release failure. 10.2.10 NC protection
GB/T 15126-94
NC protection is the scope of the NS provider's attempt to prevent unauthorized spoofing, monitoring or processing of NS user data. The protection of the NC is specified by selecting any combination of the following characteristics: a. Confidentiality of the entire NSDU sequence on the NC; b. Detection of data modification, deletion, duplication or insertion within the NSDU sequence on the NC; c. Peer entity authentication. The NS user can request the NS provider to confirm the identity of the remote NSAP, thus preventing spoofing by the mountain transport entity;
d. Identify the source of the NSDU, thus preventing unauthorized insertion or duplication of the NSDU. 10.2.11 NC Priority
NC priority independently specifies the relative importance of NCs with respect to: a. the priority of acquiring an NC;
b. the priority of maintaining an NC;
c. the priority of data on the NC.
NC priority QOS parameters a and b together define the order in which NCs are disconnected (if necessary) to recover resources. If the NS provider is able to accept new NC requests of high priority type a, it is required to do so even if doing so has to release NCs of lower priority type b.
NC priority QOS parameter c defines the order in which the QOS performance of NCs is degraded. NCs of high priority type c are served first within their requested QOS range, and the remaining resources are then used to attempt to satisfy requests on lower priority NCs. NOTE The use or activation of the NC Priority QOS parameter may be controlled by one or more of the following: user rules within a closed group of NS users;
different tariffs;
management facilities within the network layer to govern and control requests for NC priority. 10.2.12 Maximum Acceptable Cost
The Maximum Acceptable Cost QOS parameter specifies the maximum acceptable cost for the NC. Costs may be specified in absolute or relative cost units. The cost of the NC is composed of communication and end system resource costs. NOTE If the maximum acceptable cost of the NC is exceeded, the possible actions of the VS provider are not specified in this standard. Part II Definitions of Connection Mode Primitives
11 Primitive Order
This clause defines restrictions on the order in which the primitives defined in clauses 12 to 14 may appear. This restriction determines the order in which the primitives appear, but does not fully specify when they may appear. Other restrictions, such as data flow control, will affect the ability of the NS user or NS provider to send primitives at any particular time.
Table 5 is a list of NS primitives and their parameters. Table 5 Network service primitives and their parameters - List Phase
NC establishment
NC establishment
N-CONNECT
request
N-CONNECT
indlicaticon
(called address, calling address, reception confirmation selection, accelerated data selection, QUS parameter set, NS user data) (called address, calling address, reception confirmation selection, accelerated data selection, QOS parameter set, NS user data)9NC release failure probability
NC release failure probability is the ratio of the total number of NC release failures to the total number of NC release requests within a measurement sample. The NC release failure probability is usually specified independently for each NS user. For a specific NS user, if the user does not receive an N-DISCONNECT indication within the maximum delay range of NC release specified by the NS user that sent the N-DISCONNECT request (assuming that the previous NS user has not sent an N-DISCONNECT request), this phenomenon is defined as a release failure. 10.2. 10NC protection
GB/T 15126—94
NC protection is the scope of the NS provider's attempt to prevent unauthorized spoofing, monitoring or processing of NS user data. The protection of the NC is specified by selecting any combination of the following characteristics: a. Confidentiality of the entire NSDU sequence on the NC; b. Detection of data modification, deletion, duplication or insertion within the NSDU sequence on the NC; c. Peer Entity Authentication. NS users can request that NS providers verify the identity of remote NSAPs, thus preventing masquerading by transport entities:
d. Identify the origin of NSDUs, thus preventing unauthorized insertion or duplication of NSDUs. 10.2.11 NC Priority
NC Priority independently specifies the relative importance of NCs with respect to: a. the priority of acquiring an NC;
b. the priority of maintaining an NC;
c. the priority of data on an NC.
NC Priority QOS parameters a and b together define the order in which NCs are disconnected to recover resources (if necessary). The NS provider is required to accept new NC requests with a high priority type a if it is able to do so, even if doing so necessitates the release of NCs with a lower priority type b.
NC Priority QOS parameter c defines the order in which the QOS performance of NCs is degraded. NCs with higher priority type c are served first within their requested QOS range, and remaining resources are then used to attempt to satisfy requests from lower priority NCs. NOTE The use or activation of the NC Priority QOS parameter may be controlled by one or more of the following: user rules within a closed NS user group;
different tariffs;
management facilities within the network layer so that requests for NC priority are governed and controlled. 10.2.12 Acceptable Maximum Cost
The Acceptable Maximum Cost QOS parameter specifies the maximum acceptable cost for the NC. Costs may be specified in absolute or relative cost units. The cost of the NC is composed of communication and end system resource costs. NOTE If the maximum acceptable cost of the NC is exceeded, the possible actions of the VS provider are not specified in this standard. Part II Definitions of Connection Mode Primitives
11 Primitive Order
This clause defines restrictions on the order in which the primitives defined in clauses 12 to 14 may appear. This restriction determines the order in which the primitives may appear, but does not fully specify when they may appear. Other restrictions, such as data flow control, will affect the ability of the NS user or NS provider to send primitives at any particular time.
Table 5 is a list of NS primitives and their parameters. Table 5 Network service primitives and their parameters - list phase
NC establishment
NC establishment
N-CONNECT
request
N-CONNECT
indlicaticon
(called address, calling address, receive confirmation option, accelerated data option, QUS parameter set, NS user data) (called address, calling address, receive confirmation option, accelerated data option, QOS parameter set, NS user data)9NC release failure probability
NC release failure probability is the ratio of the total number of NC release failures to the total number of NC release requests within a measurement sample. The NC release failure probability is usually specified independently for each NS user. For a specific NS user, if the user does not receive an N-DISCONNECT indication within the maximum delay range of NC release specified by the NS user that sent the N-DISCONNECT request (assuming that the previous NS user has not sent an N-DISCONNECT request), this phenomenon is defined as a release failure. 10.2. 10NC protection
GB/T 15126—94
NC protection is the scope of the NS provider's attempt to prevent unauthorized spoofing, monitoring or processing of NS user data. The protection of the NC is specified by selecting any combination of the following characteristics: a. Confidentiality of the entire NSDU sequence on the NC; b. Detection of data modification, deletion, duplication or insertion within the NSDU sequence on the NC; c. Peer Entity Authentication. NS users can request that NS providers verify the identity of remote NSAPs, thus preventing masquerading by transport entities:
d. Identify the origin of NSDUs, thus preventing unauthorized insertion or duplication of NSDUs. 10.2.11 NC Priority
NC Priority independently specifies the relative importance of NCs with respect to: a. the priority of acquiring an NC;
b. the priority of maintaining an NC;
c. the priority of data on an NC.
NC Priority QOS parameters a and b together define the order in which NCs are disconnected to recover resources (if necessary). The NS provider is required to accept new NC requests with a high priority type a if it is able to do so, even if doing so necessitates the release of NCs with a lower priority type b.
NC Priority QOS parameter c defines the order in which the QOS performance of NCs is degraded. NCs with higher priority type c are served first within their requested QOS range, and remaining resources are then used to attempt to satisfy requests from lower priority NCs. NOTE The use or activation of the NC Priority QOS parameter may be controlled by one or more of the following: user rules within a closed NS user group;
different tariffs;
management facilities within the network layer so that requests for NC priority are governed and controlled. 10.2.12 Acceptable Maximum Cost
The Acceptable Maximum Cost QOS parameter specifies the maximum acceptable cost for the NC. Costs may be specified in absolute or relative cost units. The cost of the NC is composed of communication and end system resource costs. NOTE If the maximum acceptable cost of the NC is exceeded, the possible actions of the VS provider are not specified in this standard. Part II Definitions of Connection Mode Primitives
11 Primitive Order
This clause defines restrictions on the order in which the primitives defined in clauses 12 to 14 may appear. This restriction determines the order in which the primitives may appear, but does not fully specify when they may appear. Other restrictions, such as data flow control, will affect the ability of the NS user or NS provider to send primitives at any particular time.
Table 5 is a list of NS primitives and their parameters. Table 5 Network service primitives and their parameters - list phase
NC establishment
NC establishment
N-CONNECT
request
N-CONNECT
indlicaticon
(called address, calling address, reception confirmation option, accelerated data option, QUS parameter set, NS user data) (called address, calling address, reception confirmation option, accelerated data option, QOS parameter set, NS user data)
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.