title>GB/T 9387.3-1995 Information processing systems Open Systems Interconnection Basic Reference Model Part 3: Naming and addressing - GB/T 9387.3-1995 - Chinese standardNet - bzxz.net
Home > GB > GB/T 9387.3-1995 Information processing systems Open Systems Interconnection Basic Reference Model Part 3: Naming and addressing
GB/T 9387.3-1995 Information processing systems Open Systems Interconnection Basic Reference Model Part 3: Naming and addressing

Basic Information

Standard ID: GB/T 9387.3-1995

Standard Name: Information processing systems Open Systems Interconnection Basic Reference Model Part 3: Naming and addressing

Chinese Name: 信息处理系统 开放系统互连 基本参考模型 第3部分:命名与编址

Standard category:National Standard (GB)

state:Abolished

Date of Release1995-04-06

Date of Implementation:1995-01-02

Date of Expiration:2009-02-01

standard classification number

Standard ICS number:Information technology, office machinery and equipment>>Open Systems Interconnection (OSI)>>35.100.01 Open Systems Interconnection (OSI) General

Standard Classification Number:Electronic Components and Information Technology>>Information Processing Technology>>L79 Computer Open and System Interconnection

associated standards

alternative situation:Replaced by GB/T 9387.3-2008

Procurement status:≡ISO 7498-3-1989

Publication information

publishing house:China Standards Press

ISBN:155066.1-11969

Publication date:2004-08-10

other information

Release date:1995-04-06

Review date:2004-10-14

Drafting unit:Southeast University

Focal point unit:National Information Technology Standardization Technical Committee

Publishing department:State Bureau of Technical Supervision

competent authority:National Standardization Administration

Introduction to standards:

This standard defines the basic mechanisms for names and addresses used in OSIE to identify and locate objects. The use of these mechanisms is defined in the hierarchy of the basic reference model. This standard extends the concepts and criteria defined in GB 9387-88. This standard is neither intended to be an implementation specification nor a basis for evaluating implementation consistency. The canonical form of names and addresses is not within the scope of this standard. GB/T 9387.3-1995 Information Processing Systems Open Systems Interconnection Basic Reference Model Part 3: Naming and Addressing GB/T9387.3-1995 Standard download decompression password: www.bzxz.net

Some standard content:

National Standard of the People's Republic of China
Information processing system
Open Systems Interconnection
Basic Reference Model
Part 3: Naming and addressing
Information processing system-Open Systems Interconnection-Basic Reference Model-Part 3: Naming and addressingGB/T9387.3—1995
ISO 7498-3-1989
This standard is equivalent to the international standard ISO7498-3—1989 "Information processing system Open Systems Interconnection Basic Reference Model Part 3: Naming and addressing".
This standard expands the basic architecture concept of identifiers described in Section 5.4 of GB9387. This standard states an architectural principle. Any standard involving the identification (naming) and location (addressing) of objects developed for the purpose of interconnection in the Open Systems Interconnection Environment (OSIE) must comply with this standard. This standard is flexible enough to accommodate technological advances and the expansion of user requirements. This flexibility also means that existing implementations can be gradually migrated to the OSI standard.
Note: This standard is expected to be subject to future developments, especially in line with Multi-Peer Data Transfer (MPDT). The architectural principles stated in this standard ensure that any national standards involving the identification and location of objects for interconnection purposes in OSIE will:
Avoid any restrictions in the following aspects: 1) Functions that may appear in current or future national and international standards, 2)
The functions of any open real system,
The internal design of any open real system,
Retain the independence principle of the layer in OSIE. That is, the internal functions of a layer are not restricted by any other layer, b.
Retain the implementation independence principle in OSIE described in Section 4.2 of GB9387. That is, any open real system (or manager) will not need to know the implementation design of other open real systems (or managers), nor will it be necessary to expose its own implementation design as a condition for using OSI standard communication;
In OSIE, economical support is allowed for interconnection; in particular, the separate standards produced within the framework of this standard description should provide convenience for objects that need to be identified and located for interconnection in OSIE, so that they can achieve sufficient levels in performance, reliability and integrity, and reduce manual management.
In this standard, the description of naming and addressing in OSIE is divided into the following steps. Chapters 1 to 4 are basic introductions and references. Chapter 5 introduces the concept of naming.
Chapter 6 describes the objects named, addressing operations and the use of addressing in OSIE. Chapter 7 describes the purpose of naming and addressing in OSIE and the mechanisms used to meet this purpose. Approved by the State Administration of Technical Supervision on April 5, 1995 94
Implementation on December 1, 1995
GB/T 9387.3—1995
Chapter 8 describes the criteria for controlling the use and properties of addressing information in (N) services. Chapter 9 describes the criteria for controlling the use and properties of addressing information in the (N) protocol. Chapter 10 gives a description of the layer address directory function that is not specific to a particular layer and is based on the mechanisms and criteria established in Chapters 5 and 6. The directory function is the basis for supporting the addressing structure established in Chapters 7, 8, and 9. Chapter 11 specifies the use of address directory functions in each layer. Chapter 12 defines the nature of addressing domains and addressing registration authorities. Chapter 13 specifies the processes required for OSIE naming. Section 14 specifies the requirements for directory facilities in OSIE. Note: The definition of naming and addressing requirements in OSIE is not sufficient in GB9387-88, and a clear basic architecture is given in this standard. 1 Subject content and scope of application
This standard defines the basic mechanisms for names and addresses used in OSIE to identify and locate objects. The use of these mechanisms is defined in the hierarchy of the basic reference model. This standard extends the concepts and criteria defined in GB9387-88. This standard is neither intended as an implementation specification nor as a basis for evaluating the consistency of implementations. The standard form of names and addresses is not within the scope of this standard. 2 Referenced standards
This standard constitutes the rules of this standard by referencing the criteria contained in the following standards. All standards are subject to revision, and members who agree with this standard are encouraged to use the latest versions of the following standards for this part. IEC and ISO members should maintain a registration of currently valid international standards.
GB9387—88 Information Processing Systems Open Systems Interconnection Basic Reference Model GB/T15129 Information Processing Systems Open Systems Interconnection Service Agreement ISO7498 Supplement 1: 1984 Information Processing Systems Open Systems Interconnection Basic Reference Model Supplement 1: Connectionless Mode Transmission ISO7498-4: Information Processing Systems Open Systems Interconnection Basic Reference Model Part 4: OSI Management Framework ISO8348 Supplement 2: 1988 Information Processing Systems Data Communication Network Service Definition Supplement 2: Network Layer Addressing ISO9545: Information Processing Systems Open Systems Interconnection Application Layer Architecture 3 DefinitionsbzxZ.net
3.1 This standard uses the following terms defined in ISO9545: a. Application process type; b. Application process call.
3.2 This standard uses the following terms defined in GB/T 15129: a. (N) service request primitive [(N)-service-request-primitive], b. (N) service indication primitive [(N)-service-indication-primitive] [(N) service response primitive [(N)-service-response-primitive]; c.
(N) service confirmation primitive [(N)-service-confirm-primitive]. d.
3.3 This standard uses the following terms defined in Supplement 2 to ISO 8348: a. Subnet point of connection.
3.4 ​​This standard uses the following definitions:
3.4.1 (N)-address (N)-address
A name that is unambiguous in OSIE and is used to identify a set of (N) service access points located on the boundary of (N)-subsystems and (N+1)-subsystems in the same open system.
GB/T9387.3—1995
Note: ① The definition of (N)-address is the final definition, which is different from the definition in GB9387—88. When GB9387—88 is revised, it will replace the existing definition.
② When a name identifies and only identifies one object in a given scope, the name is unambiguous within the given scope. The unambiguity of a name does not exclude the existence of synonyms.
3.4.2 (N)-address-selector; (N)-selector (N)-selector An element in the addressing information that identifies a (N)-SAP set in the same (N)-subsystem. The (N)-selector is assigned by local management.
Note: The concept of (N)-address-selector applies only to layers above the network layer. 3.4.3 (N)-association (N)-association
A cooperative relationship between (N)-entity calls. Note: A (N)-association can be established by exchanging (N)-protocol control information. 3.4.4 Calling (N)-address calling-(N)-address A parameter that may appear in a (N)-service request or indication primitive that identifies the (N)-address of the (N)-originator. Note: In the service definition of a specific layer, this parameter may be referred to as the "calling (N)-address" or the "source (N)-address". However, in this standard, only "calling (N)-address" is used.
3.4.5 Called (N) address called-(N)-address A parameter that can appear in a (N) service request or indication primitive, which identifies the (N) address of the (N) recipient. Note: In the service definition of a specific layer, this parameter can be called "called (N) address" or "destination (N) address". However, in this standard, only "called (N) address" is used.
3.4.6 Descriptive name
It is a name that identifies a collection of objects through a set of assertions about the properties of the objects. 3.4.7 (N)Address Directory Function (N)-address-directory-fnuction A (N)function that processes (N)addresses, (N-1)addresses, (N)entity titles and (N)-PAIs to provide mappings between these information categories.
3.4.8 (N)Entity (N)-entity
An active element in the (N) subsystem that corresponds to a specific (N)entity type and contains a set of functions defined for the (N) layer. (Does not contain any other functions). Note: The definition of this (N)entity is different from the definition in GB9387-88. This definition is a final definition and will replace the existing definition when GB9387-88 is revised.
3.4.9 (N)Entity Invocation (N)-entity-invocationl A specific use of some or all of the functions of a given (N)entity (without using any other capabilities). Note: This definition will be introduced when GB9387-88 is revised to replace the current definition. 3.4.10 (N) Entity Title (N)-entity-title is used to unambiguously identify the name of an (N) entity. 3.4.11 (N) Entity Type (N)-entity-type is a description of a class of (N) entities based on a set of functions defined for the (N) layer. Note: This definition will be introduced when GB9387~88 is revised to replace the current definition. 3.4.12 Generic Name name
The name of a collection of objects.
Note: The generic title is a specific form of the generic name. 3.4.13 (N)-initiator (N)-initiator An (N) entity calls, which issues a (N-1) service request primitive. 3.4.14 name name
The language structure corresponding to an object in a certain domain. 96
GB/T9387.3-1995
3.4.15 Naming authority naming-authority A registration authority that assigns names according to specific rules An authority. If it is used to assign titles, it is called a title authority; if it is used to assign addresses, it is called an address authority.
3.4.16 Naming-domain
A collection of names that can be assigned to objects of a particular type. If the name is a title, the collection is called a title domain. If the name is an address, the collection is called an address domain.
3.4.17 Naming-subdomain A subset of a naming-domain that does not intersect with other naming-subdomains in the naming-domain. 3.4.18 Primitive name A name given by a designated naming authority to identify an object. Its users do not need to understand its internal structure, or its internal structure does not need to be meaningful to users. 3.4.19 (N) receiver (N)-recipient+ (N) entity calls that receive (N1) service indication primitives. 3.4.20 (N) protocol addressing information (N)-protocol-addressing-information, (N)-PAI (N)-PCI contains those elements of addressing information. 3.4.21 responding-(N)-address can be in (N ) A parameter that appears in a service response or confirmation primitive that identifies the (N) address of the (N) recipient. Note: In a service definition at a specific layer, this parameter may be referred to as the "called address" or "response address", however, in this specification, only the term "response (N) address" is used.
3.4.22 (N) service access point address (N)-service-access-point-address; (N)-SAP address (N)-SAP-address An (N) address used to identify a single (N)-SAP. Note: ① The definition of the (N) service access point address is different from that in GB9387--88. This definition is a final definition and will replace the existing definition in GB9387--88 when it is revised. ② (N) address is a general term applicable to any (N)-SAP set, including a set consisting of only one (N)-SAP. The (N)-SAP address is only used when one and only one (N)-SAP must be accurately identified. Whether an (N)-address is an (N)-SAP address is a matter for the local (N) subsystem and not for other open systems. However, in some layers, the calling (N)-address and the responding (N)-address may be restricted to identifying a single (N)-SAP because they may be used in subsequent communications (see 8.4.4 and 8.5.5). It is up to the individual layers and protocols to decide whether to use this restriction. 3.4.23 Subnetwork-address An identifier assigned to a point of connection to a subnetwork by the naming authority of the subnetwork. 3.4.24 Synonymous name A synonym identifies a name for an object that is already identified by a different name. Synonymous generic names are different generic names that identify the same set.
system-title
3.4.25 System-title
A name used to identify a single real open system that is unique within OSIE. 4 Abbreviations
In this standard, the following abbreviations are used: (N)-CEPI
(N)-PAI
(N)Connection Endpoint Identifier
Data Link Service Access Point
.Network Service Access Point
Open Systems Interconnection
OSI Environment
(N)Protocol Addressing Information
(N)-PCI
(N)-SA P
5 Basic concepts of naming
GB/T9387.3-1995
(N) Protocol control information
Physical service access point
Presentation service access point
(N) Service access point
Connected subnet point
Session service access point
Transport service access point
5.1 Names are language structures expressed in a language. They correspond to objects in a certain domain. The correspondence between names (in the language) and objects (in the domain) is an identification relationship. A name identifies the object it restricts. 5.2 In the OSI context, a name identifies a specific communication object in the Open Systems Interconnection Environment (OSIE). There are two distinct types of names, namely, primitive names and descriptive names.
5.3 In any particular domain, an primitive name is a name assigned to a specific object by a naming authority. A naming authority is only a source of names. The only structural restriction on the naming authority is that the names it provides must satisfy: a. be described in a specified language;
b. be unambiguous (identify only one object). 5.4 A descriptive name consists of a set of assertions expressed in a formally defined language. The definition of the formal language determines the language structure of the descriptive names it generates. A descriptive name can be incomplete, in which case multiple objects satisfy all assertions, or it can be complete, in which case it identifies only a single object. A complete descriptive name is equivalent to a primitive name, in which case it uniquely identifies one object. A component of a descriptive name can be several primitive names. 5.5 Although a primitive name is unambiguous, there can be multiple unambiguous names identifying the same object. 5.6 A generic name is a primitive name or a descriptive name. It identifies a set of several objects. When two generics are used to indicate one object each, the result is that only one element of the set is selected. Generic names can be used to identify a collection of special types of objects that do not need to be located in an open system.
5.7 When a name is used to distinguish between different objects and retrieve information related to an object from a directory facility, it is assigned to an object as a title. When a name is used to distinguish between different object types and retrieve information related to an object type from a directory facility, it is assigned to an object type as a title. This name can identify a system, an application process, an application process type, an (N) entity, or an (N) entity type.
Note: The definitions of these objects and types are both in GB9387-88 and ISO9545. 5.8 When a name is used only to distinguish between occurrences of an object, it is assigned as an identifier to that object. This name may identify a (N) association, an application process call or a (N) entity call. NOTE: The definitions of these objects are in both GB9387-88 and ISO9545. 6 OSI naming and addressing concepts and the correct use of addresses 6.1 Naming of real open systems
6.1.1 The system title is a primitive name that is independent of the layer, that is, the same identifier can be used to identify the same real open system in different layers. A single real open system is named by and only by a system title. 6.1.2 The system title is used to identify the real open system as a whole. It may also be used: a. in conjunction with other qualifiers to identify a specific OSI resource stored in the relevant part of the management information base of the real open system; b. as an attribute attached to a directory facility entry of an OSI resource that is only related to a single real open system. 6.2 Naming and addressing of (N)-layer elements
6.2.1 Introduction
GB/T 9387.3--1995
6.2.1.1 Since an (N)-entity type describes a class of (N)-entities, it needs to be named but not located. Since (N)-entities and (N)-entity calls are active elements in the (N)-layer, they need to be unambiguously identified and located. 6.2.1.2 In an open system, (N+1)-entities and (N)-entities are connected to each other by an (N)-service access point ((N)-SAP). By exchanging service primitives at the (N)-SAP, the (N)-entity provides services to the (N+1)-entity. 6.2.1.3 An (N)-entity is unambiguously identified by an (N)-entity title. An (N)-entity type is identified by an (N)-entity type title. An (N)-entity call is identified by an (N)-entity call identifier, which is unambiguous within the scope of an (N)-entity.
6.2.2 (N)-address
6.2.2.1 An (N)-address identifies a set of (N)-SAPs, all of which are located at the interface of an (N)-subsystem and an (N+1)-subsystem. An (N)-SAP address is an (N)-address, but it identifies a set consisting of only one (N)-SAP. 6.2.2.2 When multiple (N)-entities are addressed, communication with an address is communication with an (N)-entity call. 6. 2.2.3 An (N+1)-entity is located by one or more (N)-SAPs to which it is attached. An (N)-SAP is identified by one or more (N)-addresses.
Note: A physical address is used to access a data link entity, a data link address is used to access a network entity, a network address is used to access a transport entity, a transport address is used to access a session entity, a session address is used to access a presentation entity; and a presentation address is used to access an application entity. 6.2.3 (N)-selector
An (N)-selector is a component of the addressing information that is specific to the (N)-subsystem. Once an end open system is unambiguously identified, the (N)-selector is used within that end open system to identify the (N)-SAP or a collection of (N)-SAPs. Since the end open system is implicit at the network layer, the (N)-selector is only used above the network layer, where it is used with local information to locate the required (N+1) entity within the open system. The value of the (N)-selector is exchanged between open systems as part of the (N)-PAI. 6.3 Correct use of (N)-addresses
6.3.1 (N)-addresses have a limited range of use. They are used to distinguish (N)-SAP sets and only to distinguish (N)-SAP sets. The use of addressing conventions does not make the structure of the actual open system visible to the OSI environment. 6.3.2 (N)-addresses are used to identify (N)-SAP sets to locate (N+1) entities. An (N+1) subsystem may be divided into several (N+1) entities as follows:
To support different (N+1) protocols or (N+1) protocol sets; to meet security or management requirements;
In the application subsystem, to distinguish between different application processes and different application entities in the same application process. 6.3.3 (N)-addresses are not used to:
To distinguish between negotiated parts (class, subset, quality of service, protocol version) or parameter values ​​in the protocol, to derive routing information above the network layer;
To distinguish between hardware components.
NOTE: In some configurations, the use of (N)-addresses as defined in clause 6.3.2 may result in an (N+1) entity being completely contained in a single hardware component. However, in OSIE, the (N) address identifies the (N+1) entity, it does not identify a hardware component. 7 OSI Addressing Model
7.1 Associations between peer (N) entities
7.1.1 An (N) association is a cooperative relationship between two (N) entity calls. Cooperation between (N) entity calls requires the establishment and maintenance of relevant state information in each (N) entity call. This state information supports the (N) associations between (N) entity calls. 7.1.2 An (N) entity call may support one or more independent (N) associations at any time. The communication behavior between the (N) entity call and a particular (N) association is defined by the (N) entity and the state information specific to the (N) association, which is maintained by the (N) entity call.
An (N) association identifier is associated with each (N) association. This identifier is unique within the scope of a pair of cooperating (N)-entity invocations. It is used to identify state information associated with each (N)-entity invocation. The identifier consists of two parts, each (N)-entity invocation determines the (N)-contact identifier. Note: Some (N) protocols may not need to specify an (N)-contact identifier. 7.1.4 Two (N)-entity invocations may establish several (N-1)-connections, or use (N-1) connectionless services to support (N)-contacts. The lifetime of an (N)-contact may exceed any (N-1)-connection that supports it. The constraints between an (N)-contact and an (N-1)-connection may change at any time. Note: An (N)-contact may be associated with multiple (N-1)-connections, but at a certain time there is only a one-to-one constraint with one (N-1)-connection; however, in the case of a split, there may be a one-to-many constraint at a certain time. 7.1.5 When required by an (N)-related operation, the (N)-entity title is used to identify the (N)-entity but is not related to its location. When required by an (N)-related operation, the (N-1) address is used to request the (N-1) service to identify the location of the relevant (N)-entity. 7.2 Connection of (N)-Entity to (N)-SAP
An (N)-entity can provide (N) services through one or more (N)-SAPs, and can also obtain (N-1) services through one or more (N-1)-SAPs. As a result, the (N)-entity can have the following relationship with (N)-SAPs and (N-1)-SAPs (see Figure 1): (N)SAP
(N)SAP
(N-1) SAP
Multiple (NI)SAPs
Multiple (N)SAPs
Multiple (N)SAPs
Multiple (N-1) SAH
Figure 1 Relationship between (N)-entity and (N)-SAP and (N-1)-SAP 100
GB/T9387.3—1995
A (N)-entity can use the (N1) service provided by a (N-1)-SAP and provide (N) services through a (N)-SAP.
A (N)-entity can use the (N-1) service provided by a (N-1)-SAP and provide (N) services through multiple (N)-SAPs. b.
(N) services.
A (N)-entity can use the (N-1) service provided by multiple (N-1)-SAPs and provide (N) services through a (N)-SAP.
d. A (N)-entity can use the (N-1) service provided by multiple (N-1)-SAPs and provide (N) services through multiple (N)-SAPs.
Note: ① The correspondence between the SAPs and entities identified above has nothing to do with multiplexing. An (N) multiplexing function is to map multiple (N) connections to a (N-1) connection. Several (N) connections can all terminate at one (N)-SAP or at multiple separate (N)-SAPs. Multiplexed (N) connections can be distinguished from each other at the service boundary by (N)-PCI elements and (N)-PAI elements (such as the contact identifier in the (N) protocol).
②X.25 (ISO8208) and the connection reference in the OSI transport protocol (GB12500) are information exchanged in the (N)PCI to distinguish instances of connections when multiplexing is used. 7.3 (N)-addresses and (N)-SAPs
7.3.1 The OSI addressing structure allows:
a. The (N)-address is used to identify the location of an (N+1) entity within the open system to which it refers, without limiting the lower layer subsystems;
b. Multiple (N)-entities are defined within an (N)-subsystem. NOTE: Some addressing structures allow a presentation address to be used to identify the location of an application entity without limiting the presentation, session, and transport subsystem structures in the open system; and also allow a single set of addressing information to be defined for establishing communications with an application entity in the receiving system. 7.3.2 An (N)-address identifies a set of (N)-SAPs, all of which are located on the boundary of the same (N)-subsystem. The exact number of members of the set is a local matter for the (N)-subsystem. The number of members of the set is unknown to other open systems and may vary during its lifetime.
7.3.3 The set of (N)-SAPs identified by an (N)-address may consist of any of the following: a. a single (N)-SAP connected to an (N+1) entity; or b. multiple (N)-SAPs connected to an (N+1) entity; or c. multiple (N)-SAPs connected to different (N+1) entities. 7.3.4 When an (N)-address is used as the called (N)-address in a service primitive, the receiving (N)-subsystem shall select an (N)-SAP from the set identified by the (N)-address. This selection mechanism is a local matter that is transparent to the (N)-initiator. 7.3.5 The open system shall be appropriately configured to ensure that all (N)-SAPs in the set identified by an (N)-address are connected to (N+1) entities of the same type and thus provide the same functionality. 7.3.6 In a given open system, it is important to correctly distinguish between the semantics of an (N)-address and the syntax used to represent an (N)-address. An (N)-address is carried across layer boundaries in an open system as a parameter of an (N)-service primitive. For an (N)-service request or response primitive, the semantics of the (N)-address will be conveyed to the peer (N)-subsystem and passed across the layer boundary as a parameter in an (N)-service indication or confirmation primitive. The (N)-service conveys only the semantics of the (N)-address. The syntax of the (N)-address is a local matter and different open systems may use different syntaxes.
7.3.7 When an (N+1)-entity establishes an (N)-connection with another (N+1)-entity, each (N+1)-entity obtains an (N)-connection endpoint identifier L(N)-CEPI (see Section 5.4.2 of GB9387-88) from the (N)-entity that supports it. - An (N)-CEPI is a local identifier determined when the connection is established. An (N)-CEPI cannot be considered a replacement for an (N)-address. When the calling (N)-address and the called (N)-address of an (N)-connection are identical, the (N)-connection has two (N)-endpoint identifiers and two (N)-CEPIs (a (N)-entity-to-itself connection). How these two (N)-CEPIs are distinguished in an (N)-subsystem is entirely a local matter.
7.4 (N)-directory functions and (N)-directory facilities 101
GB/T9387.3—1995
7.4.1 (N)-directory functions process (N)-addresses, (N-1)-addresses, (N)-entity titles, and (N)-PAIs to provide mappings between these information categories. The information used to perform these mappings is maintained by the directory facility. It is the responsibility of the local system administration to access the directory facility to retrieve the relevant information and make it available to an (N)-directory function. 7.4.2 Some of this information represents the logical structure of the local end system and affects local operations. They are stored locally. The remainder of this information represents the logical structure of the remote system and affects the generation of the (N)-PAI. It may be stored locally or remotely. If remote storage is used, access to this information requires the use of OSI protocols. 8 Addressing Information and (N) Services
8.1 Introduction
8.1.1 This clause presents a layer-independent description of the (N) addresses used in (N) service primitives. 8.1.2 (N+1) entities use (N) services by issuing (N) service primitives via (N)-SAPs. Issuance of an (N) service request or response primitive may result in the issuance of an (N) service indication or confirmation primitive by an (N)-SAP connected to the peer (N+1) entity. 8.1.3 The (N) address retrieved from information provided by a directory facility may be invalid. The (N)Address retrieved from the calling or responding (N)Address parameter of a previously received (N)ServiceIndication or Confirm primitive is valid only at the time it is issued, but is not guaranteed to be valid forever. Therefore, in all cases, an (N+1) entity using an (N)Address should check whether the (N)Address is still communicating with the expected responder in the (N+1) layer. In this case, the usual practice is to exchange application entity headers in the application layer. 8.1.4 The use of an (N)Address does not in itself identify a specific (N+1)EntityInvocation. An (N+1)Entity may communicate with any instance of the expected (N+1)Entity at a certain (N)Address. In some (N+1) layers, it is necessary to refer to the (N+1)EntityInvocationIdentifier used by the (N+1)EntityInvocation. 8.2 Address Parameters
8.2.1 It is important to distinguish whether the (N)Address parameter passed is a called (N)Address parameter or a calling (N)Address or a responding (NAddress parameter.
8.2.2 The called (N) address is used to initiate communications between (N+1) entity calls. The (N+1) initiator provides the called (N) address, and its semantics are conveyed to the peer (N+1) recipient.
8.2.3 The calling (N) address and the responding (N) address are primarily used for identification and recall purposes, and can identify the specific (N)-SAP used in a communication instance.
8.3 Called (N) address
8.3.1 The called (N) address parameter in the connection mode service primitive is equivalent to the destination (N) address parameter in the connectionless mode service primitive.
8.3.2 The called (N) address is provided by the (N+1) initiator. The semantics of the (N) address are conveyed to the recipient's (N) subsystem and (N+1) subsystem in a (N) service indication primitive.
8.3.3 There is no restriction that the called (N) address carried in the parameters of the (N)service indication primitive be identical to the address specified in the associated request primitive. However, the (N)service definition may make use of this restriction. 8.3.4 Above the network layer, address processing is constrained by the end systems: 8. For the initiating open system, processing of the called (N) address does not depend on the complexity of the address structure supported by the receiving open system;
b. For the receiving open system, processing of the called (N) address depends on the complexity of the address structure supported by that system. 8.3.5 At the network layer, although processing of some called (N) addresses may occur in an intermediate system, this processing does not depend on the complexity of the address structure supported by the receiving open system. 8.3.6 The called (N) address identifies a set of (N)-SAPs of the receiving (N) subsystem. Any (N)-SAP within the set may be used to support communications. It is the responsibility of the receiving subsystem to resolve the address to select a specific (N)-SAP. 8.3.7 The called (N) address may have been retrieved from information obtained from the directory facility. In this case, the semantics of the (N) address are related to the self-entry entry published by the receiving system through its own behavior. The attributes associated with the self-entry entry must be known to the receiving subsystem. The called (N) address identifies a set of (N)-SAPs that access (N+1) entities that support communications in a manner consistent with the information obtained from the directory facility. 8.3.8 The called (N) address may be an (N) address that has been passed by the receiving (N) subsystem as a calling or responding (N) address parameter in a previous communication instance. In this case, the (N)-SAP set it identifies is consistent with the requirements for calling or responding (N) addresses described in clauses 8.4 and 8.5.
8.3.9 The called (N) address may be obtained by special arrangements. At this point, the called (N) address identifies a set of (N)-SAPs that provide access to (N+1) entities that support communications in a manner consistent with the dedicated arrangement. :8.4 Calling (N) Address
8.4.1 The calling (N) address parameter in the connection mode service primitive is equivalent to the source (N) address parameter in the connectionless mode service primitive. 8.4.2 The calling (N) address is provided by the (N+1) initiator. The semantics of the (N) address is conveyed to the receiving (N) subsystem and then passed to the (N+1) subsystem using an (N) service indication primitive. 8.4.3 The existing (N) protocol specification and OSI management standards do not impose any restrictions. The receiving (N+1) subsystem may use the calling (N) address in any of the following ways:
a. In a subsequent request primitive unrelated to the original communication, use the calling (N) address in the original communication as the called (N) address; b. In order to facilitate the reestablishment or disconnection of the connection, use the calling (N) address in the original communication as the called (N) address in a subsequent request primitive related to the original communication;
c. Forwarded to other open systems as a called (N) address; d. for administrative purposes.
8.4.4 During its validity period, the calling (N) address shall identify a set of (N)-SAPs located at the initiating (N) entity. This set may be limited by the requirements of the calling (N) address hierarchy specification. For example, a layer may require that a calling (N) address only identifies one (N)-SAP to actually support the initiating communication.
8.4.5 When the calling (N) address in an (N) service indication primitive is used by the receiving (N) subsystem as the called (N) address in a subsequent (N) service request primitive, the subsystem should be aware that this address may no longer be valid as defined in clause 8.4.4 and should take appropriate action.
8.5 Response (N) address
8.5.1 The response (N) address is used in the (N) service response/confirmation primitive. NOTE: Some OSI services use the term "called address" to refer to the response (N) address parameter when defining response and confirmation primitives. 8.5.2 The response (N) address is provided by the (N+1) receiver. The semantics of the (N) address is conveyed to the initiating (N) subsystem and passed to the initiating (N+1) subsystem in a confirmation service primitive. 8.5.3 There are no restrictions imposed by existing (N) layer protocol specifications and OSI management standards. The initiating (N+1) subsystem may use the response (N) address in any of the following ways:
a. Use the response (N) address in the original communication as the called (N) address in a subsequent request primitive that is not related to the original communication; b. Use the response (N) address in the original communication as the called (N) address in a subsequent request primitive that is related to the original communication. For example, to facilitate the reestablishment or disconnection of the connection; c. Forwarded as the called (N) address to other open system, d. for management purposes.
8.5.4 The response (N) address may be different from the called (N) address specified in the associated (N) service indication primitive. 8.5.5 During its validity period, the response (N) address shall identify a set of (N)-SAPs located at the initiating (N) entity. This set may be limited by the requirements of the response (N) address hierarchy specification. For example, a layer may require that a response (N) address only identifies one (N)-SAP to actually support communications.
8.5.6 When a response (N) address received in an (N) service confirmation primitive is used by the initiating subsystem as the called (N) address in a subsequent (N) service request primitive, the subsystem should be aware that this address may no longer be valid as defined in clause 8.5.5 and should take appropriate action.
9 Addressing information and (N) protocol
9.1 Introduction
GB/T 9387.3—1995
This clause gives a layer-independent description of the use of addressing information in the (N)-Protocol Addressing Information [(N)-PAI]. The (N)-PAI is the element of the (N)-PCI that contains addressing information. 9.2 Addressing Information in the (N)-PAI
9.2.1 The semantics of (N)-addresses are conveyed by exchanging (N)-protocols between invocations of (N)-entities. For some layers, the full semantics of (N)-addresses are conveyed in the (N)-PAI. In other layers, it may not be necessary to represent (N)-PAI. The full semantics of the (N)-address. For these layers, the full semantics of the (N)-address is conveyed by a combination of: a. Exchange of (N)-PAI;
b. Local information related to the scope of use of the (N)-PAI. Note: ① For example, network entities exchange network addresses. In this case, the Network-PAI contains the network address. ② The value of the (N)-PAI may contain information related to the operation of the (N) layer and the (N+1) layer. However, a particular layer only uses information related to that layer.
9.2.2 Below the network layer, communicating (N) entities are restricted to a single subnet. Since the exchange of (N)-PAI can be translated within the scope of a subnet, this exchange does not have to be globally applicable. 9.2.3 At the network layer, communicating (N) entities can be connected to different subnets. Therefore, the exchange of (N)-PAI must be globally applicable. Therefore, in order to achieve the purpose of exchanging the Network-PAI, the full semantics of the network address needs to be provided separately. 9.2.4 Above the network layer, the scope of the (N)-PAI is limited to the communicating end systems. In these layers, the semantics of the (N)-address consists of: a. the identification of an (N)-SAP set, which is unambiguous within the scope of the (N)-subsystem containing the set and is provided by the (N)-selectors exchanged in the (N)-PAI and local information about the scope of application of the selectors in the corresponding (N)-subsystems; b. the identification of the end system comes from the exchange of network addresses in the network layer. NOTE: The application layer exchanges headers and identifiers rather than addressing information. 9.3 Assignment of (N)-PAI elements
9.3.1 The layer protocol specifications define the elements of the (N)-PAI for the exchange of addressing information. The different elements of the (N)-PAI are used to convey the following semantics:
called (N) address,
calling (N) address,
a responding (N) address.
9.3.2 The value of the element used to convey the semantics of the calling (N) address is provided by the (N) initiator. This value may be retained by the receiving (N) subsystem and conveyed to the original initiating (N) subsystem in subsequent request primitives as the semantics of the called (N) address. 9.3.3 The semantic value of the responding (N) address is provided by the receiving (N) subsystem. This value may be retained by the initiating (N) subsystem and conveyed to the receiving (N) subsystem in subsequent (N) service request primitives as the semantics of the called (N) address. 9.3.4 The semantic value of the called (N) address may come from: a. a directory facility,
b. a private arrangement, or
a previously issued (calling) responding (N) address. 9.4 Network Addresses and Network-PAI
The complete semantics of the network address are conveyed in the Network-PAI. Network addresses are globally applicable and are issued by the appropriate registration authority. 9.5 (N)-Addresses and (N)-PAIs at Layers Above the Network Layer 9.5.1 The (N)-selection factor is unambiguous within an (N)-subsystem. The value of the (N)-selection factor is chosen by local management of the open system, and although the value so chosen must be known to the subsystems with which it wishes to communicate, this does not require the establishment of an OSI addressing structure. When an (N)-selection factor identifies an (N)-SAP, the resolution of the selector is the task of the receiving (N)-subsystem. NOTES: ① All (N)-entities specific to a particular (N)-SAP set are connected to that (N)-SAP set in the same manner (i.e., the value of the (N)-selection factor associated with the corresponding (N)-SAP set is always the same, regardless of which of the (N)-entities handles the communication). ② How unambiguity is achieved is a local matter. Local management of the open system can be achieved by defining selectors that are unique within the scope of the (N)-subsystem. In this case, the semantics of the (N)-selector can be retrieved from the value carried by the (N)-PAI, regardless of the (N)-entity responsible for handling the communication. When the (N)-selector is unambiguous but not unique within the scope of the (N)-subsystem: additional information local to the receiving open system is required (in particular, the semantics of some (N)-selectors are dependent on the (N)-entity handling the communication),
9.5.2 The protocol specification may specify that (N)-PAI is an optional item and may therefore be omitted. Since (N)-PAI is the (N)-selective factor in the (N)-protocol, there is no difference between the (N)-selective factor being default and the (N)-selective factor value being empty. In connected mode operation, the (N)-selective factor default for both the calling and called (N)-addresses is equivalent to the (N)-selective factor value being empty. For the responding (N)-address, the (N)-selective factor value default indicates that the responding (N)-address is the called (N)-address. Note: In the hierarchy using the type-length-value (TLV) encoding technique: a. "Selective factor default" means that no parameter for transporting this factor type is present; b. "Selective factor value is empty" corresponds to a zero length field for the parameter for transporting this factor type; c.
is considered empty.
If the parameter type for transporting the selective factor type is present and there is If the associated parameter length is not zero, then the selector value is not encoded, regardless of whether it is encoded. 9.5.3 When the selector value is "null" (or the default for that value) it is used in the (N)-PAI to convey the semantics of the called (N)-address only when it has been specified as follows:
a. a value from a directory facility entry; or b. the (N)-PAI conveyed is a previously issued (N)-PAI for the semantics of the calling, responding (N)-address c. a private arrangement.
9.5.4 The (N)-recipient uses the (N) selector with a null value to select an (N)-SAP based on local information. NOTE: The use of a null selector by local administration of an open system does not affect the use of other (N) selector values. . 9.6 Obtaining (N)-PAI
9.6.1 Information about the application entity is obtained from the application title directory facility (see Chapter 14). This information is a single tuple that specifies the addressing (N)-PAI value required to access the application entity through the PSAP. This tuple has the following form: P selection factor, S selection factor, T selection factor, network address table).
Note: Each (N)-PAI value retrieved from this four-tuple can be used by the relevant (N) receiver to identify an (N)-SAP set. The fact that the (N) addressing information can identify an (N)-SAP set is only known to the receiving (N) subsystem. 9.6.2 All network addresses in the network address table belong to the same open system. In the initiating open system, for a given For a communication instance, a network address value is selected by the local system management. 9.6.3 The T selection factor is a single T selection factor value that, when used in a transport PAI, identifies a set of TSAPs located in the relevant open system and applicable to the network address in the quad. The value of this selection factor is equally valid regardless of which network address is used. 9.6.4 The S selection factor is a single S selection factor value that, when used in a session PAI, identifies a set of SSAPs located in the relevant open system and applicable to the network address in the quad. The value of this selection factor is equally valid regardless of which network address is used. 9.6.5 The P selection factor is a single P selection factor value that, when used in a presentation PAI, identifies a set of PSAPs located in the relevant open system and applicable to the network address in the quad. The value of this selection factor is equally valid regardless of which network address is used. 10 (N) Directory Functions
10.1 Introduction
10.1.1 (N) Directory Functions are used to process (N) addresses, (N1) addresses, (N) entity headers, (N)-PAI and possible routing information to provide mappings between these information categories. These functions are performed by the (N) entity in the (N) layer in the following situations during connection establishment or connectionless data transmission:
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.