Network Working Group Richard Colella (NIST) Request for Comments: 1237 Ella Gardner (Mitre) Ross Callon (DEC) July 1991 Guidelines for OSI NSAP Allocation in the Internet
Status of This Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the ‘‘IAB Official Protocol
Standards’’ for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI in the Internet, an OSI lower layers
infrastructure is required. This infrastructure comprises the
connectionless network protocol (CLNP) and supporting routing
protocols. Also required as part of this infrastructure are guidelines for network service access point (NSAP) address assignment. This paper provides guidelines for allocating NSAPs in the Internet.
This document provides our current best judgment for the allocation
of NSAP addresses in the Internet. This is intended to guide initial
deployment of OSI 8473 (Connectionless Network Layer Protocol) in
the Internet, as well as to solicit comments. It is expected that
these guidelines may be further refined and this document updated as a result of experience gained during this initial deployment.
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
Contents
1 Introduction 4
2 Scope 4
3 Background 6 3.1 OSI Routing Standards . . . . . . . . . . . . 7 3.2 Overview of DIS10589 . . . . . . . . . . . . 8
3.3 Requirements of DIS10589 on NSAPs . . . . . . . . 11
4 NSAP and Routing 13
5 NSAP Administration and Routing in the Internet 17 5.1 Administration at the Area . . . . . . . . . . 19 5.2 Administration at the Leaf Routing Domain . . . . . 21 5.3 Administration at the Transit Routing Domain . . . . 21 5.3.1 Regionals . . . . . . . . . . . . . . 22 5.3.2 Backbones . . . . . . . . . . . . . . 23 5.4 Multi-homed Routing Domains . . . . . . . . . . 24 5.5 Private Links . . . . . . . . . . . . . . . 29 5.
6 Zero-Homed Routing Domains . . . . . . . . . . 30 5.
7 Transition Issues . . . . . . . . . . . . . 31
6 Recommendations 34 6.1 Recommendations Specific to U.S. Parts of the Internet . 35
Colella, Gardner, & Callon [Page 2]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
6.2 Recommendations Specific to Non-U.S. Parts of the Internet 37
6.3 Recommendations for Multi-Homed Routing Domains . . . 37
7 Security Considerations 38
8 Authors’ Addresses 39
9 Acknowledgments 39
A Administration of NSAPs 40 A.1 GOSIP Version 2 NSAPs . . . . . . . . . . . . 41 A.1.1 Application for Administrative Authority Identifiers 42 A.1.2 Guidelines for NSAP Assignment . . . . . . . 44 A.2 Data Country Code NSAPs . . . . . . . . . . . 45 A.2.1 Application for Numeric Organization Name . . . 46 A.3 Summary of Administrative Requirements . . . . . . 46
Colella, Gardner, & Callon [Page 3]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 1 Introduction
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI in the Internet, an OSI lower layers
infrastructure is required. This infrastructure comprises the
connectionless network protocol (CLNP) [12] (see also RFC 994 [8])
and supporting routing protocols. Also required as part of this
infrastructure are guidelines for network service access point (NSAP)
address assignment. This paper provides guidelines for allocating
NSAPs in the Internet (NSAP and NSAP address are used interchangeably
throughout this paper in referring to NSAP addresses).
The remainder of this paper is organized into five major sections and
an appendix. Section 2 defines the boundaries of the problem addressed in this paper and Section 3 provides background information on OSI
routing and the implications for NSAPs.
Section 4 addresses the specific relationship between NSAPs and
routing, especially with regard to hierarchical routing and data
abstraction. This is followed in Section 5 with an application of
these concepts to the Internet environment. Section 6 provides
recommended guidelines for NSAP allocation in the Internet.
Appendix A contains a compendium of useful information concerning
NSAP structure and allocation authorities. The GOSIP Version 2 NSAP
structure is discussed in detail and the structure for U.S.-based DCC
(Data Country Code) NSAPs is described. Contact information for the
registration authorities for GOSIP and DCC-based NSAPs in the U.S.,
the General Services Administration (GSA) and the American National
Standards Institute (ANSI), respectively, is provided.
2 Scope
There are two aspects of interest when discussing OSI NSAP allocation
within the Internet. The first is the set of administrative require-
ments for obtaining and allocating NSAPs; the second is the technical
aspect of such assignments, having largely to do with routing, both
within a routing domain (intra-domain routing) and between routing
Colella, Gardner, & Callon [Page 4]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 domains (inter-domain routing). This paper focuses on the technical
issues.
The technical issues in NSAP allocation are mainly related to routing. This paper assumes that CLNP will be widely deployed in the Internet,
and that the routing of CLNP traffic will normally be based on the OSI ES-IS (end-system to intermediate system) routing protocol applicable
for point-to-point links and LANs [13] (see also RFC 995 [7]) and
the emerging intra-domain IS-IS protocol [17]. Also expected is the
deployment of an inter-domain routing protocol similar to Border
Gateway Protocol (BGP) [18].
The guidelines provided in this paper are intended for immediate
deployment as CLNP is made available in the Internet. This paper
specifically does not address long-term research issues, such as
complex policy-based routing requirements.
In the current Internet many routing domains (such as corporate and
campus networks) attach to transit networks (such as NSFNET regionals) in only one or a small number of carefully controlled access points.
Addressing solutions which require substantial changes or constraints
on the current topology are not considered.
The guidelines in this paper are oriented primarily toward the large-
scale division of NSAP address allocation in the Internet. Topics
covered include:
* Arrangement of parts of the NSAP for efficient operation of the
DIS10589IS-IS routing protocol;
* Benefits of some topological information in NSAPs to reduce
routing protocol overhead;
* The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
* The recommended mapping between Internet topological entities
(i.e., backbone networks, regional networks, and site networks)
and OSI addressing and routing components;
* The recommended division of NSAP address assignment authority
among backbones, regionals (also called mid-levels), and sites;
Colella, Gardner, & Callon [Page 5]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 * Background information on administrative procedures for registra- tion of administrative authorities immediately below the national level (GOSIP administrative authorities and ANSI organization
identifiers); and,
* Choice of the high-order portion of the NSAP in leaf routing
domains that are connected to more than one regional or backbone. It is noted that there are other aspects of NSAP allocation, both
technical and administrative, that are not covered in this paper.
Topics not covered or mentioned only superficially include:
* Identification of specific administrative domains in the Internet; * Policy or mechanisms for making registered information known to
third parties (such as the entity to which a specific NSAP or a
potion of the NSAP address space has been allocated);
* How a routing domain (especially a site) should organize its
internal topology of areas or allocate portions of its NSAP
address space; the relationship between topology and addresses is discussed, but the method of deciding on a particular topology or internal addressing plan is not; and,
* Procedures for assigning the System Identifier (ID) portion of the NSAP.
3 Background
Some background information is provided in this section that is
helpful in understanding the issues involved in NSAP allocation. A
brief discussion of OSI routing is provided, followed by a review
of the intra-domain protocol in sufficient detail to understand the
issues involved in NSAP allocation. Finally, the specific constraints
that the intra-domain protocol places on NSAPs are listed.
Colella, Gardner, & Callon [Page 6]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 3.1 OSI Routing Standards
OSI partitions the routing problem into three parts:
* routing exchanges between end systems and intermediate systems
(ES-IS),
* routing exchanges between ISs in the same routing domain (intra-
domain IS-IS), and,
* routing among routing domains (inter-domain IS-IS).
ES-IS, international standard ISO9542 [13] approved in 1987, is
available in vendor products and is planned for the next release of
Berkeley UNIX (UNIX is a trademark of AT&T). It is also cited in GOSIP Version 2 [4], which became effective in April 1991 for all applicable federal procurements, and mandatory beginning eighteen months later in 1992.
Intra-domain IS-IS advanced to draft international standard (DIS)
status within ISO in November, 1990 as DIS10589 [17]. It is reasonable to expect that final text for the intra-domain IS-IS standard will be
available by mid-1991.
There are two candidate proposals which address OSI inter-domain
routing, ECMA TR/50 [3] and Border Router Protocol (BRP) [19], a
direct derivative of the IETF Border Gateway Protocol [18]. ECMA TR/50 has been proposed as base text in the ISO/IEC JTC1 SC6/WG2 committee,
which is responsible for the Network layer of the ISO Reference Model
[11 ].X3S3.3, the ANSI counterpart to WG2, has incorporated features
of TR/50 into BRP and submitted this as alternate base text at the
WG2 meeting in October, 1990. Currently, it is out for ISO Member
Body comment. The proposed protocol is referred to as the Inter-domain Routing Protocol (IDRP) [20].
This paper examines the technical implications of NSAP assignment
under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing
are deployed to support CLNP.
Colella, Gardner, & Callon [Page 7]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 3.2 Overview of DIS10589
The IS-IS intra-domain routing protocol, DIS10589, developed in ISO,
provides routing for OSI environments. In particular, DIS10589 is
designed to work in conjunction with CLNP and ES-IS. This section
briefly describes the manner in which DIS10589 operates.
In DIS10589, the internetwork is partitioned into routing domains.
A routing domain is a collection of ESs and ISs that operate common
routing protocols and are under the control of a single administra-
tion. Typically, a routing domain may consist of a corporate network,
a university campus network, a regional network, or a similar contigu- ous network under control of a single administrative organization. The boundaries of routing domains are defined by network management by
setting some links to be exterior, or inter-domain, links. If a link
is marked as exterior, no DIS10589 routing messages are sent on that
link.
Currently, ISO does not have a standard for inter-domain routing
(i.e., for routing between separate autonomous routing domains). In
the interim, DIS10589 uses manual configuration. An inter-domain link
is statically configured with the set of address prefixes reachable
via that link, and with the method by which they can be reached (such
as the DTE address to be dialed to reach that address, or the fact
that the DTE address should be extracted from the OSI NSAP address).
DIS10589 routing makes use of two-level hierarchical routing. A
routing domain is subdivided into areas (also known as level 1
subdomains). Level 1 ISs know the topology in their area, including
all ISs and ESs in their area. However, level 1 ISs do not know the
identity of ISs or destinations outside of their area. Level 1 ISs
forward all traffic for destinations outside of their area to a level
2 IS within their area.
Similarly, level 2 ISs know the level 2 topology and know which
addresses are reachable via each level 2 IS. The set of all level 2
ISs in a routing domain are known as the level 2 subdomain, which can
be thought of as a backbone for interconnecting the areas. Level 2
ISs do not need to know the topology within any level 1 area, except
to the extent that a level 2 IS may also be a level 1 IS within a
single area. Only level 2 ISs can exchange data packets or routing
information directly with external ISs located outside of their
Colella, Gardner, & Callon [Page 8]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 routing domain.
As illustrated in Figure 1, ISO addresses are subdivided into the
Initial Domain Part (IDP) and the Domain Specific Part (DSP), as spec- ified in ISO8348/Addendum 2, the OSI network layer addressing standard [14 ](also RFC 941 [6]). The IDP is the part which is standardized by
ISO, and specifies the format and authority responsible for assigning
the rest of the address. The DSP is assigned by whatever addressing
authority is specified by the IDP (see Appendix A for more discussion
on the top level NSAP addressing authorities). The DSP is further
subdivided, by DIS10589, into a High Order Part of DSP (HO-DSP), a
system identifier (ID), and an NSAP selector (SEL). The HO-DSP may
use any format desired by the authority which is identified by the
IDP. Together, the combination of [IDP,HO-DSP] identify an area within a routing domain and, implicitly, the routing domain containing the
area. The combination of [IDP,HO-DSP] is therefore referred to as the
area address.
_______________________________________________
!____IDP_____!_______________DSP______________!
!__AFI_!_IDI_!_____HO-DSP______!___ID___!_SEL_!
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
HO-DSP High-order DSP
ID System Identifier
SEL NSAP Selector
Figure 1: OSI Hierarchical Address Structure.
The ID field may be from one to eight octets in length, but must have
a single known length in any particular routing domain. Each router is configured to know what length is used in its domain. The SEL field is always one octet in length. Each router is therefore able to identify
the ID and SEL fields as a known number of trailing octets of the NSAP address. The area address can be identified as the remainder of the
address (after truncation of the ID and SEL fields).
Usually, all nodes in an area have the same area address. However,
sometimes an area might have multiple addresses. Motivations for
allowing this are several:
Colella, Gardner, & Callon [Page 9]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 * It might be desirable to change the address of an area. The most
graceful way of changing an area from having address A to having
address B is to first allow it to have both addresses A and B, and then after all nodes in the area have been modified to recognize
both addresses, one by one the ESs can be modified to forget
address A.
* It might be desirable to merge areas A and B into one area. The
method for accomplishing this is to, one by one, add knowledge of
address B into the A partition, and similarly add knowledge of
address A into the B partition.
* It might be desirable to partition an area C into two areas, A and B (where A might equal C, in which case this example becomes one
of removing a portion of an area). This would be accomplished by
first introducing knowledge of address A into the appropriate ESs
(those destined to become area A), and knowledge of address B into the appropriate nodes, and then one by one removing knowledge of
address C.
Since the addressing explicitly identifies the area, it is very easy
for level 1 ISs to identify packets going to destinations outside
of their area, which need to be forwarded to level 2 ISs. Thus, in
DIS10589 the two types of ISs route as follows:
* Level 1 intermediate systems -- these nodes route based on the ID
portion of the ISO address. They route within an area. Level 1 ISs recognize, based on the destination address in a packet, whether
the destination is within the area. If so, they route towards the
destination. If not, they route to the nearest level 2 IS.
* Level 2 intermediate systems -- these nodes route based on address prefixes, preferring the longest matching prefix, and preferring
internal routes over external routes. They route towards areas,
without regard to the internal structure of an area; or towards
level 2 ISs on the routing domain boundary that have advertised
external address prefixes into the level 2 subdomain. A level 2 IS may also be operating as a level 1 IS in one area.
A level 1 IS will have the area portion of its address manually
configured. It will refuse to become a neighbor with an IS whose area
addresses do not overlap its own area addresses. However, if a level 1
IS has area addresses A, B, and C, and a neighbor has area addresses
Colella, Gardner, & Callon [Page 10]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 B and D, then the level 1 IS will accept the other IS as a level 1
neighbor.
A level 2 IS will accept another level 2 IS as a neighbor, regardless
of area address. However, if the area addresses do not overlap, the
link would be considered by both ISs to be level 2 only, and only
level 2 routing packets would flow on the link. External links (i.e.,
to other routing domains) must be between level 2 ISs in different
routing domains.
DIS10589 provides an optional partition repair function. In the
unlikely case that a level 1 area becomes partitioned, this function,
if implemented, allows the partition to be repaired via use of level 2 routes.
DIS10589 requires that the set of level 2 ISs be connected. Should the level 2 backbone become partitioned, there is no provision for use of
level 1 links to repair a level 2 partition.
In unusual cases, a single level 2 IS may lose connectivity to the
level 2 backbone. In this case the level 2 IS will indicate in its
level 1 routing packets that it is not attached, thereby allowing
level 1 ISs in the area to route traffic for outside of the area
to a different level 2 IS. Level 1 ISs therefore route traffic to
destinations outside of their area only to level 2 ISs which indicate
in their level 1 routing packets that they are attached.
An ES may autoconfigure the area portion of its address by extracting
the area portion of a neighboring IS’s address. If this is the case,
then an ES will always accept an IS as a neighbor. Since the standard
does not specify that the end system must autoconfigure its area
address, an end system may be pre-configured with an area address. In
this case the end system would ignore IS neighbors with non-matching
area addresses.
3.3 Requirements of DIS10589 on NSAPs
The preferred NSAP format for DIS10589 is shown in Figure 1. A number
of points should be noted from DIS10589:
Colella, Gardner, & Callon [Page 11]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 * The IDP is as specified in ISO 8348/Addendum 2, the OSI network
layer addressing standard [14];
* The high-order portion of the DSP (HO-DSP) is that portion of the DSP whose assignment, structure, and meaning are not constrained
by DIS10589;
* The concatenation of the IDP and the HO-DSP, the area address,
must be globally unique (if the area address of an NSAP matches
one of the area addresses of a system, it is in the system’s area and is routed to by level 1 routing);
* Level 2 routing acts on address prefixes, using the longest
address prefix that matches the destination address;
* Level 1 routing acts on the ID field. The ID field must be unique within an area for ESs and level 1 ISs, and unique within the
routing domain for level 2 ISs. The ID field is assumed to be
flat;
* The one-octet NSAP Selector, SEL, determines the entity to receive the CLNP packet within the system identified by the rest of the
NSAP (i.e., a transport entity) and is always the last octet of
the NSAP; and,
* A system shall be able to generate and forward data packets
containing addresses in any of the formats specified by ISO
8348/Addendum 2. However, within a routing domain that conforms to DIS10589, the lower-order octets of the NSAP should be structured as the ID and SEL fields shown in Figure 1 to take full advantage of DIS10589 routing. End systems with addresses which do not
conform may require additional manual configuration and be subject to inferior routing performance.
For purposes of efficient operation of the IS-IS routing protocol,
several observations may be made. First, although the IS-IS protocol
specifies an algorithm for routing within a single routing domain, the routing algorithm must efficiently route both: (i) Packets whose final destination is in the domain (these must, of course, be routed to the
correct destination end system in the domain); and (ii) Packets whose
final destination is outside of the domain (these must be routed to a
correct ‘‘border’’ router, from which they will exit the domain).
Colella, Gardner, & Callon [Page 12]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 For those destinations which are in the domain, level 2 routing treats the entire area address (i.e., all of the NSAP address except the ID
and SEL fields) as if it were a flat field. Thus, the efficiency of
level 2 routing to destinations within the domain is affected only by
the number of areas in the domain, and the number of area addresses
assigned to each area (which can range from one up to a maximum of
three).
For those destinations which are outside of the domain, level 2
routing routes according to address prefixes. In this case, there
is considerable potential advantage (in terms of reducing the amount
of routing information that is required) if the number of address
prefixes required to describe any particular set of destinations can
be minimized.
4 NSAPs and Routing
When determining an administrative policy for NSAP assignment, it
is important to understand the technical consequences. The objective
behind the use of hierarchical routing is to achieve some level
of routing data abstraction, or summarization, to reduce the cpu,
memory, and transmission bandwidth consumed in support of routing.
This dictates that NSAPs be assigned according to topological
routing structures. However, administrative assignment falls along
organizational or political boundaries. These may not be congruent to
topological boundaries and therefore the requirements of the two may
collide. It is necessary to find a balance between these two needs.
Routing data abstraction occurs at the boundary between hierarchically arranged topological routing structures. An element lower in the
hierarchy reports summary routing information to its parent(s). Within the current OSI routing framework [16] and routing protocols, the
lowest boundary at which this can occur is the boundary between an
area and the level 2 subdomain within a DIS10589 routing domain. Data
abstraction is designed into DIS10589 at this boundary, since level 1
ISs are constrained to reporting only area addresses, and a maximum
number of three area addresses are allowed in one area (This is an
architectural constant in DIS10589. See [17], Clause 7.2.11 and Table
2 of Clause 7.5.1).
Colella, Gardner, & Callon [Page 13]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 Level 2 routing is based upon address prefixes. Level 2 ISs dis-
tribute, throughout the level 2 subdomain, the area addresses of the
level 1 areas to which they are attached (and any manually configured
reachable address prefixes). Level 2 ISs compute next-hop forwarding
information to all advertised address prefixes. Level 2 routing is
determined by the longest advertised address prefix that matches the
destination address.
At routing domain boundaries, address prefix information is exchanged
(statically or dynamically) with other routing domains. If area
addresses within a routing domain are all drawn from distinct NSAP
assignment authorities (allowing no abstraction), then the boundary
prefix information consists of an enumerated list of all area
addresses.
Alternatively, should the routing domain ‘‘own’’ an address prefix
and assign area addresses based upon it, boundary routing information
can be summarized into the single prefix. This can allow substantial
data reduction and, therefore, will allow much better scaling (as
compared to the uncoordinated area addresses discussed in the previous paragraph).
If routing domains are interconnected in a more-or-less random (non-
hierarchical) scheme, it is quite likely that no further abstraction
of routing data can occur. Since routing domains would have no defined hierarchical relationship, administrators would not be able to assign
area addresses out of some common prefix for the purpose of data
abstraction. The result would be flat inter-domain routing; all
routing domains would need explicit knowledge of all other routing
domains that they route to. This can work well in small- and medium-
sized internets, up to a size somewhat larger than the current IP
Internet. However, this does not scale to very large internets. For
example, we expect growth in the future to an international Internet
which has tens or hundreds of thousands of routing domains in the U.S. alone. This requires a greater degree of data abstraction beyond that
which can be achieved at the ‘‘routing domain’’ level.
In the Internet, however, it should be possible to exploit the
existing hierarchical routing structure interconnections, as discussed in Section 5. Thus, there is the opportunity for a group of routing
domains each to be assigned an address prefix from a shorter prefix
assigned to another routing domain whose function is to interconnect
the group of routing domains. Each member of the group of routing
Colella, Gardner, & Callon [Page 14]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 domains now ‘‘owns’’ its (somewhat longer) prefix, from which it
assigns its area addresses.
The most straightforward case of this occurs when there is a set
of routing domains which are all attached only to a single regional
(or backbone) domain, and which use that regional for all external
(inter-domain) traffic. A small address prefix may be assigned to
the regional, which then assigns slightly longer prefixes (based
on the regional’s prefix) to each of the routing domains that it
interconnects. This allows the regional, when informing other
routing domains of the addresses that it can reach, to abbreviate
the reachability information for a large number of routing domains
as a single prefix. This approach therefore can allow a great deal
of hierarchical abbreviation of routing information, and thereby can
greatly improve the scalability of inter-domain routing.
Clearly, this approach is recursive and can be carried through several iterations. Routing domains at any ‘‘level’’ in the hierarchy may
use their prefix as the basis for subsequent suballocations, assuming
that the NSAP addresses remain within the overall length and structure constraints. The GOSIP Version 2 NSAP structure, discussed later in
this section, allows for multiple levels of routing hierarchy.
At this point, we observe that the number of nodes at each lower
level of a hierarchy tends to grow exponentially. Thus the greatest
gains in data abstraction occur at the leaves and the gains drop
significantly at each higher level. Therefore, the law of diminishing
returns suggests that at some point data abstraction ceases to
produce significant benefits. Determination of the point at which data abstraction ceases to be of benefit requires a careful consideration
of the number of routing domains that are expected to occur at each
level of the hierarchy (over a given period of time), compared to the
number of routing domains and address prefixes that can conveniently
and efficiently be handled via dynamic inter-domain routing protocols. There is a balance that must be sought between the requirements
on NSAPs for efficient routing and the need for decentralized NSAP
administration. The NSAP structure from Version 2 of GOSIP (Figure 2)
offers an example of how these two needs might be met. The AFI,
IDI, DFI, and AA fields provide for administrative decentralization.
The AFI/IDI pair of values 47/0005 identify the U.S. government
as the authority responsible for defining the DSP structure and
allocating values within it (see Appendix A for more information on
NSAP structure).
Colella, Gardner, & Callon [Page 15]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 [Note: It is not important that NSAPs be allocated from the
GOSIP Version 2 authority under 47/0005. The ANSI format under
the Data Country Code for the U.S. (DCC=840) and formats
assigned to other countries and ISO members or liaison
organizations are also expected to be used, and will work
equally well. For parts of the Internet outside of the U.S.
there may in some cases be strong reasons to prefer a local
format rather than the GOSIP format. However, GOSIP addresses
are used in most cases in the examples in this paper because:
* The DSP format has been defined and allows hierarchical
allocation; and,
* An operational registration authority for suballocation of
AA values under the GOSIP address space has already been
established at GSA.]
GOSIP Version 2 defines the DSP structure as shown (under DFI=80h) and provides for the allocation of AA values to administrations. Thus, the fields from the AFI to the AA, inclusive, represent a unique address
prefix assigned to an administration.
_______________
!<--__IDP_-->_!___________________________________
!AFI_!__IDI___!___________<--_DSP_-->____________!
!_47_!__0005__!DFI_!AA_!Rsvd_!_RD_!Area_!ID_!Sel_!
octets !_1__!___2____!_1__!_3_!__2__!_2__!_2___!_6_!_1__!
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 2: GOSIP Version 2 NSAP structure.
Currently, a proposal is being progressed in ANSI for an American
National Standard (ANS) for the DSP of the NSAP address space
Colella, Gardner, & Callon [Page 16]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 administered by ANSI. This will provide an identical DSP structure
to that provided by GOSIP Version 2. The ANSI format, therefore,
differs from that illustrated above only in that the IDP is based
on an ISO DCC assignment, and in that the AA will be administered
by a different organization (ANSI secretariat instead of GSA).
The technical considerations applicable to NSAP administration are
independent of whether a GOSIP Version 2 or an ANSI value is used for
the NSAP assignment.
Similarly, although other countries may make use of slightly different NSAP formats, the principles of NSAP assignment and use are the same.
In the low-order part of the GOSIP Version 2 NSAP format, two
fields are defined in addition to those required by DIS10589. These
fields, RD and Area, are defined to allow allocation of NSAPs along
topological boundaries in support of increased data abstraction.
Administrations assign RD identifiers underneath their unique address
prefix (the reserved field is left to accommodate future growth and
to provide additional flexibility for inter-domain routing). Routing
domains allocate Area identifiers from their unique prefix. The result is:
* AFI+IDI+DFI+AA = administration prefix,
* administration prefix(+Rsvd)+RD = routing domain prefix, and,
* routing domain prefix+Area = area address.
This provides for summarization of all area addresses within a routing domain into one prefix. If the AA identifier is accorded topological
significance (in addition to administrative significance), an
additional level of data abstraction can be obtained, as is discussed
in the next section.
5 NSAP Administration and Routing in the Internet
Internet routing components---backbones, regionals, and sites
or campuses---are arranged hierarchically for the most part. A
natural mapping from these components to OSI routing components
is that backbones, regionals, and sites act as routing domains.
Colella, Gardner, & Callon [Page 17]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 (Alternatively, a site may choose to operate as an area within a
regional. However, in such a case the area is part of the regional’s
routing domain and the discussion in Section 5.1 applies. We assume
that some, if not most, sites will prefer to operate as routing
domains. By operating as a routing domain, a site operates a level 2
subdomain as well as one or more level 1 areas.)
Given such a mapping, where should address administration and alloca-
tion be performed to satisfy both administrative decentralization and
data abstraction? Three possibilities are considered:
1. at the area,
2. at the leaf routing domain, and,
3. at the transit routing domain (TRD).
Leaf routing domains correspond to sites, where the primary purpose is to provide intra-domain routing services. Transit routing domains are
deployed to carry transit (i.e., inter-domain) traffic; backbones and
regionals are TRDs.
The greatest burden in transmitting and operating on routing informa-
tion is at the top of the routing hierarchy, where routing information tends to accumulate. In the Internet, for example, regionals must man- age the set of network numbers for all networks reachable through the
regional. Traffic destined for other networks is generally routed to
the backbone. The backbones, however, must be cognizant of the network numbers for all attached regionals and their associated networks.
In general, the advantage of abstracting routing information at a
given level of the routing hierarchy is greater at the higher levels
of the hierarchy. There is relatively little direct benefit to the
administration that performs the abstraction, since it must maintain
routing information individually on each attached topological routing
structure.
For example, suppose that a given site is trying to decide whether
to obtain an NSAP address prefix based on an AA value from GSA
(implying that the first four octets of the address would be those
assigned out of the GOSIP space), or based on an RD value from its
regional (implying that the first seven octets of the address are
those assigned to that regional). If considering only their own
Colella, Gardner, & Callon [Page 18]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 self-interest, the site itself, and the attached regional, have
little reason to choose one approach or the other. The site must use
one prefix or another; the source of the prefix has little effect
on routing efficiency within the site. The regional must maintain
information about each attached site in order to route, regardless of
any commonality in the prefixes of the sites.
However, there is a difference when the regional distributes routing
information to backbones and other regionals. In the first case, the
regional cannot aggregate the site’s address into its own prefix;
the address must be explicitly listed in routing exchanges, resulting
in an additional burden to backbones and other regionals which must
exchange and maintain this information.
In the second case, each other regional and backbone sees a single
address prefix for the regional, which encompasses the new site. This
avoids the exchange of additional routing information to identify the
new site’s address prefix. Thus, the advantages primarily accrue to
other regionals and backbones which maintain routing information about this site and regional.
One might apply a supplier/consumer model to this problem: the higher
level (e.g., a backbone) is a supplier of routing services, while
the lower level (e.g., an attached regional) is the consumer of these
services. The price charged for services is based upon the cost of
providing them. The overhead of managing a large table of addresses
for routing to an attached topological entity contributes to this
cost.
The Internet, however, is not a market economy. Rather, efficient
operation is based on cooperation. The guidelines discussed below
describe reasonable ways of managing the OSI address space that
benefit the entire community.
5.1 Administration at the Area
If areas take their area addresses from a myriad of unrelated NSAP
allocation authorities, there will be effectively no data abstraction
beyond what is built into DIS10589. For example, assume that within a
routing domain three areas take their area addresses, respectively,
out of:
Colella, Gardner, & Callon [Page 19]
RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991 * the GOSIP Version 2 authority assigned to the Department of
Commerce, with an AA of nnn:
AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;
* the GOSIP Version 2 authority assigned to the Department of the
Interior, with an AA of mmm:
AFI=47, IDI=0005, DFI=80h, AA=mmm, ... ; and,
* the ANSI authority under the U.S. Data Country Code (DCC) (Section A.2) for organization XYZ with ORG identifier = xxx:
AFI=39, IDI=840, DFI=dd, ORG=xxx, ....
As described in Section 3.3, from the point of view of any particular
routing domain, there is no harm in having the different areas in
the routing domain use addresses obtained from a wide variety of
administrations. For routing within the domain, the area addresses are treated as a flat field.
However, this does have a negative effect on inter-domain routing,
particularly on those other domains which need to maintain routes to
this domain. There is no common prefix that can be used to represent
these NSAPs and therefore no summarization can take place at the
routing domain boundary. When addresses are advertised by this routing domain to other routing domains, an enumerated list must be used
consisting of the three area addresses.
This situation is roughly analogous to the dissemination of routing
information in the TCP/IP Internet. Areas correspond roughly to
networks and area addresses to network numbers. The result of allowing areas within a routing domain to take their NSAPs from unrelated
authorities is flat routing at the area address level. The number
of address prefixes that leaf routing domains would advertise is on
the order of the number of attached areas; the number of prefixes a
regional routing domain would advertise is approximately the number of areas attached to the client leaf routing domains; and for a backbone
this would be summed across all attached regionals. Although this
situation is just barely acceptable in the current Internet, as the
Internet grows this will quickly become intractable. A greater degree
of hierarchical information reduction is necessary to allow continued
growth in the Internet.
Colella, Gardner, & Callon [Page 20]
PI 实时数据库系统详细介绍 PI.实时数据库系统---详细介绍2010-08-20 11：50PI实时数据库系统(Plant Information System)是由美国OSI Software公司开发的基于C/S、 B/S结构的商品化软件应用平台，是工厂底层控制网络与上层治理信息系统连 接的桥梁，PI在工厂信息集成中扮演着特别和重要的角色。 PI实时数据库系统适用于电力、石油、化工、冶金、造纸、制药、水处理、食品饮料、通讯等各种生产流程企业的生产过程优化。 PI是全世界装机量最多的实时数据库系统，已成为OSI公司的标志产品。 美国OSI Software公司创建于1980年，总部设在加州San Leandro。在休斯顿、西雅图、克里夫兰设有分部，在美国的IL、FL、MO、MA、NY、NC等州设有办事处，在澳大利亚、新西兰、德国、新加坡设有办事处，全球范围有超过50 多个分销商，智网科技(杭州)有限公司是OSI Software公司在中国的指定分销商。同时，智网科技还利用自身的技术优势，在PI系统的平台上，二次开发了诸多的电厂应用子系统，使用户十分方便地进行电厂生产过程优化及安全运行 治理。 OSI Software公司与Microsoft、SAP、KBC等闻名公司保持着良好的合作 关系，PI的客户端产品中底层完全采用微软Windows技术，同时也将用户界面Windows化。迄今为止，PI的客户端模块以功能强盛、灵活、易用的特点在业 界一直保持着领先的地位。OSI Software公司还与世界上几乎所有的DCS/PLC 厂商保持着良好合作关系，这就使得PI与DCS/PLC的数据接口建立在坚实的基础之上。 PI实时数据库系统概述世界上众多的企业都熟悉到生产过程的实时数据与 历史数据是企业最有价值的信息财富，是整个企业信息系统的核心和基础。但是，假如生产现场缺乏数据，数据不完整或者不一致，以及历史数据丢失，都 将导致管理者对工厂的现状无法判断，给管理带来困难，严峻时甚至导致工厂 停产，发生事故等等。二十年来，OSI Software公司一直致力于实时数据库产 品的开发工作，使得PI系统成为世界上最优秀的实时数据库产品。
OSI模型七个层的作用及工作原理 OSI模型，即开放式通信系统互联参考模型，是国际标准化组织(ISO)提出的一个试图使各种计算机在世界范围内互联为网络的标准框架。OSI模型分为物理层、数据链路层、网络层、传输层、会话层、表示层和应用层，在本文对这七个层的作用及工作原理做简单介绍。OSI/RM协议是由ISO(国际标准化组织)制订的，它的基本功能是：提供给开发者一个必需的、通用的概念以便开发完善、可以用来解释连接不同系统的框架。根据标准，OSI模型分七层，见图1，用这些规定来实现网络数据的传输。 图1 OSI模型
1、物理层(Physical Layer) OSI模型的最底层或第一层。该层包括物理联网媒介，如电缆连线连接器，主要是对物理连接方式、电气特性、机械特性等做一些规定，制订相关标准，这样大家就可以按照相同的标准开发出通用的产品，很明显直流24V与交流220V是无法对接的，因此就要统一标准，大家都用直流24V吧，至于为什么采用24V呢？您就当是争执各方妥协的结果吧。所以，这层标准解决的是数据传输所应用的设备标准的问题。 物理层的协议产生并检测电压，以便发送和接收携带数据的信号。尽管物理层不提供纠错服务，但它能够设定数据传输速率并监测数据出错率，网络物理问题，如电线断开，将影响物理层。用户要传递信息就要利用一些物理媒体，如双绞线、同轴电缆等，但具体的物理媒体并不在0SI的7层之内，有人把物理媒体当做第0层，物理层的任务就是为它的上一层提供一个物理连接，以及它们的机械、电气、功能和过程特性。如规定使用电缆和接头的类型、传送信号的电压等。在这一层，数据还没有被组织，仅作为原始的位流或电气电压处理，请注意，我们所说的通信仅仅指数字通信方式，因此，数据的单位是比特(位-bit)。 2、数据链路层(Datalink Layer) OSI模型的第二层。它控制网络层与物理层之间的通信，解决的是所传输的数据的准确性的问题。 数据链路层的主要功能是如何在不可靠的物理线路上进行数据的可
O S I七层模型与各层设 备对应 -CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN
OSI七层模型与各层设备对应 OSI七层网络模型由下至上为1至7层，分别为物理层(Physical layer)，数据链路层(Data link layer)，网络层(Network layer)，传输层(Transport layer)，会话层(Session layer)，表示层(Presentation layer)，应用层(Application layer)。 应用层，很简单，就是应用程序。这一层负责确定通信对象，并确保由足够的资源用于通信，这些当然都是想要通信的应用程序干的事情。为操作系统或网络应用程序提供访问网络服务的接口。 应用层协议的代表包括：Telnet、FTP、HTTP、SNMP等。 表示层，负责数据的编码、转化，确保应用层的正常工作。这一层，是将我们看到的界面与二进制间互相转化的地方，就是我们的语言与机器语言间的转化。数据的压缩、解压，加密、解密都发生在这一层。这一层根据不同的应用目的将数据处理为不同的格式，表现出来就是我们看到的各种各样的文件扩展名。 会话层，负责建立、维护、控制会话，区分不同的会话，以及提供单工(Simplex)、半双工(Half duplex)、全双工(Full duplex)三种通信模式的服务。我们平时所知的NFS，RPC,X Windows等都工作在这一层。管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。 传输层，负责分割、组合数据，实现端到端的逻辑连接。数据在上三层是整体的，到了这一层开始被分割，这一层分割后的数据被称为段(Segment)。三次握手(Three-way handshake)，面向连接(Connection-Oriented)或非面向连接(Connectionless-Oriented)的服务，流控(Flow control)等都发生在这一层。是第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。 在这一层，数据的单位称为数据段（segment）。 传输层协议的代表包括：TCP、UDP、SPX等 网络层，负责管理网络地址，定位设备，决定路由。我们所熟知的IP地址和路由器就是工作在这一层。上层的数据段在这一层被分割，封装后叫做包(Packet)，包有两种，一种叫做用户数据包(Data packets)，是上层传下来的用户数据；另一种叫路由更新包(Route update packets)，是直接由路由器发出来的，用来和其他路由器进行路由信息的交换。负责对子网间的数据包进行路由选择。网络层还可以实现拥塞控制、网际互连等功能。
全球及中国实时数据库系统市场分析来源：计世网 一、2008年全球实时数据库系统市场规模突破5亿美元 上世纪八十年代，随着国外众多针对实时领域和数据领域进行数据融合的研究群体的显现，实时数据库那个新兴研究领域开始浮出水面。到上世纪九十年代，国外实时数据库开始大规模应用。随着应用的持续推广，国外实时数据库技术得到了持续的提升，显现了众多开发实时数据库系统的厂家，如美国OSI公司、美国INSTEP公司、GE-Fanuc公司、美国Won derware公司等，事实上时数据库产品广泛应用在电力、钢铁、化工等众多领域。到21世纪初期，实时数据库市场进展也大致趋于平稳。据美国软件与信息产业协会与汉鼎咨询的联合统计，以后5-10年间全球实时数据库的总体潜在市场容量为100亿美元，随着全世界越来越认识到实时数据库在工业及其他领域信息化建设中发挥的重要作用，目前全世界实时数据库市场规模也在加大，2008年的市场规模为5亿美元。 在上世纪九十年代，我国实时数据库市场一直被国外品牌所垄断，国内没有自主品牌的实时数据库产品。随着国家鼓舞进展软件行业政策的出台，以及国内企业对实时数据库系统的重视度持续提升、研究持续深入，国内实时数据库产品产生。到目前为止，国内实时数据库在理论和实践上均取得了专门大的进展，部分产品差不多可与进口品牌相比美。然而作为一个通用的产品开发和应用平台，国内可用的杰出的产品还不多，组态软件厂商提供的低端实时数据库仍旧大量充斥市场，中高端品牌比较有代表性的有上海麦杰科技openPlant、三维力控pSpace、中科启信Agilor等，高端市场目前仍旧被国外产品如PI、EDNA等所占据。 二、2008年中国实时数据库系统市场规模2.64亿元，石化、电力、钢铁三大领域占据绝对份额 依据中国机电一体化协会工业实时数据库分会与汉鼎咨询的联合统计，2008年，国内实时数据库销售总量近500套，当年市场销售额2.64亿元，估量2009年达到611套，较上年增长24.6%。以后4-5年我国实时数据库系统的总体潜在市场规模在17-25亿元。
OSI 七层模型各层的功能。 OSI 七层模型各层的功能。第七层：应用层数据用 户接口，提供用户程序“接口”。 第六层：表示层数据数据的表现形式，特定功能的实现，如数据加密。 第五层：会话层数据允许不同机器上的用户之间建立会话 关系，如WINDOWS 第四层：传输层段实现网络不同主机上用户进程之间的数 与不可靠的传输，传输层的错误检测，流量控制等。 第三层：网络层包提供逻辑地址（IP）、选路，数据从源端 到目的端的传输第二层：数据链路层帧将上层数据封装成帧，用MAC 地址访问媒介，错误检测与修正。 第一层：物理层比特流设备之间比特流的传输，物理接口，电气特性等。下面是对OSI 七层模型各层功能的详细解释： OSI 七层模型OSI 七层模型称为开放式系统互联参考模型 OSI 七层模型是一种框架性的设计方法 OSI 七层模型通过七个层次化的结构模型使不同的系统不
同的网络之间实现可靠的通讯，因此其最主要的功能使就是帮助不同类型的主机实现数据传输物理层：O S I 模型的最低层或第一层，该层包括物理连 网媒介，如电缆连线连接器。物理层的协议产生并检测电压络接口卡，你就建立了计算机连网的基础。换言之，你提供了一个物理层。尽管物理层不提供纠错服务，但它能够设定数据传输速率并监测数据出错率。网络物理问题，如电线断开，将影响物理层。 以便发送和接收携带数据的信号。在你的桌面P C 上插入网 数据链路层：O S I 模型的第二层，它控制网络层与物理层之间的通信。它的主要功能是如何在不可靠的物理线路上进行数据的可靠传递。为了保证传输，从网络层接收到的数据被分割成特定的可被物理层传输的帧。帧是用来移动数据的结构包，它不仅包括原始数据，还包括发送方和接收方的网络地址以及纠错和控制信息。其中的地址确定了帧将发送到何处，而纠错和控制信息则确保帧无差错到达。 数据链路层的功能独立于网络和它的节点和所采用的物理层类型，它也不关心是否正在运行Wo r d 、E x c e l 或使用I n t e r n e t 。有一些连接设备，如交换机，由于它们要对帧解码并使用帧信息将数据发送到正确的接收方，所以它们是工作在数据链路层的。 网络层：O S I 模型的第三层，其主要功能是将网络地址翻
OSI Open Source Initiative（简称OSI，有译作开放源代码促进会、开放原始码组织）是一个旨在推动开源软件发展的非盈利组织。OSI参考模型（OSI/RM）的全称是开放系统互连参考模型（Open System Interconnection Reference Model，OSI/RM），它是由国际标准化组织ISO提出的一个网络系统互连模型。它是网络技术的基础，也是分析、评判各种网络技术的依据，它揭开了网络的神秘面纱，让其有理可依，有据可循。 一、OSI参考模型知识要点 图表1：OSI模型基础知识速览 模型把网络通信的工作分为7层。1至4层被认为是低层，这些层与数据移动密切相关。5至7层是高层，包含应用程序级的数据。每一层负责一项具体的工作，然后把数据传送到下一层。由低到高具体分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。 第7层应用层—直接对应用程序提供服务，应用程序可以变化，但要包括电子消息传输 第6层表示层—格式化数据，以便为应用程序提供通用接口。这可以包括加
密服务 第5层会话层—在两个节点之间建立端连接。此服务包括建立连接是以全双工还是以半双工的方式进行设置，尽管可以在层4中处理双工方式第4层传输层—常规数据递送－面向连接或无连接。包括全双工或半双工、流控制和错误恢复服务 第3层网络层—本层通过寻址来建立两个节点之间的连接，它包括通过互连网络来路由和中继数据 第2层数据链路层—在此层将数据分帧，并处理流控制。本层指定拓扑结构并提供硬件寻址 第1层物理层—原始比特流的传输 电子信号传输和硬件接口数据发送时，从第七层传到第一层，接受方则相反。 各层对应的典型设备如下： 应用层……………….计算机：应用程序，如FTP，SMTP，HTTP 表示层……………….计算机：编码方式，图像编解码、URL字段传输编码 会话层……………….计算机：建立会话，SESSION认证、断点续传 传输层……………….计算机：进程和端口 网络层…………………网络：路由器，防火墙、多层交换机 数据链路层………..网络：网卡，网桥，交换机 物理层…………………网络：中继器，集线器、网线、HUB 二、OSI基础知识 OSI/RM参考模型的提出 世界上第一个网络体系结构由IBM公司提出（74年，SNA），以后
OSI七层模型与各层设备对应 OSI七层网络模型由下至上为1至7层，分别为物理层(Physical layer)，数据链路层(Data link layer)，网络层(Network layer)，传输层(Transport layer)，会话层(Session layer)，表示层(Presentation layer)，应用层(Application layer)。 应用层，很简单，就是应用程序。这一层负责确定通信对象，并确保由足够的资源用于通信，这些当然都是想要通信的应用程序干的事情。为操作系统或网络应用程序提供访问网络服务的接口。 应用层协议的代表包括：Telnet、FTP、HTTP、SNMP等。 表示层，负责数据的编码、转化，确保应用层的正常工作。这一层，是将我们看到的界面与二进制间互相转化的地方，就是我们的语言与机器语言间的转化。数据的压缩、解压，加密、解密都发生在这一层。这一层根据不同的应用目的将数据处理为不同的格式，表现出来就是我们看到的各种各样的文件扩展名。 会话层，负责建立、维护、控制会话，区分不同的会话，以及提供单工(Simplex)、半双工(Half duplex)、全双工(Full duplex)三种通信模式的服务。我们平时所知的NFS，RPC,X Windows等都工作在这一层。管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。 传输层，负责分割、组合数据，实现端到端的逻辑连接。数据在上三层是整体的，到了这一层开始被分割，这一层分割后的数据被称为段(Segment)。三次握手(Three-way handshake)，面向连接(Connection-Oriented)或非面向连接(Connectionless-Oriented)的服务，流控(Flow control)等都发生在这一层。是第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。 在这一层，数据的单位称为数据段（segment）。 传输层协议的代表包括：TCP、UDP、SPX等 网络层，负责管理网络地址，定位设备，决定路由。我们所熟知的IP地址和路由器就是工作在这一层。上层的数据段在这一层被分割，封装后叫做包(Packet)，包有两种，一种叫做用户数据包(Data packets)，是上层传下来的用户数据；另一种叫路由更新包(Route update packets)，是直接由路由器发出来的，用来和其他路由器进行路由信息的交换。负责对子网间的数据包进行路由选择。网络层还可以实现拥塞控制、网际互连等功能。 在这一层，数据的单位称为数据包（packet）。 网络层协议的代表包括：IP、IPX、RIP、OSPF等 数据链路层，负责准备物理传输，CRC校验，错误通知，网络拓扑，流控等。我们所熟知的MAC地址和交换机都工作在这一层。上层传下来的包在这一层被分割封装后叫做帧(Frame)。在不可靠的物理介质上提供可靠的传输。该层的作用
企标分类号： 备案号：Q/LTH 四川泸天化股份有限公司企业标准 Q/LTHGF ***-20XX 实时数据库系统管理制度 20XX-XX-XX发布20XX-XX-XX实施四川泸天化股份有限公司 发布 标准化管理委员会
Q/LTHGF ***-2011 Ⅰ 目次 1 范围 (1) 2 术语和定义 (1) 3 组织机构及职责................................................. 错误！未定义书签。 4 数据服务器的管理 (1) 5 OPC服务器的管理 (2) 6 客户端的管理 (2) 7 系统组态管理 (3) 8 系统安全管理 (3) 9 罚则 (3)
Q/LTHGF xxx -2011 III 前 言 为加强泸天化股份公司（以下简称“公司”）生产现场信息管理、科学、准确、及时收集、传递现场过程信息，及时掌握装置运行动态，促进安全长周期生产，根据实时数据库系统的网络结构，按照分级管理、各司其职的原则，结合公司实际情况，特制定本管理制度。 本标准由四川泸天化股份有限公司行政部提出。 本标准由四川泸天化股份有限公司行政部归口。 本标准起草人：朱城江 初审人：陈伟， 傅宇， 崔宇辉 复审人： 终审人： 本部分所代替标准的历次版本发布情况为： ——LTHGF ZD G-2009-243
Q/LTHGF xxx -2011 1 实时数据库系统管理制度 1 范围 本标准规定了公司实时数据库系统管理的要求。 本标准适用于公司所有使用实时数据库系统的单位和个人用户。 2 术语定义 2.1 实时数据库系统 指以计算机网络技术为基础，采用开放、标准的OPC 协议，利用OPC 服务器对生产现场过程数据进行采集、存储和监视的信息系统。 2.2 OPC 协议 OPC 是用于过程控制的OLE(OLE for Process Control)的首字母缩写词，是用于Windows 应用程序与现场过程控制应用之间进行数据通信的一种工业标准。 2.3 OPC 服务器 指通过OPC 协议采集现场过程数据并传送给实时数据库数据服务器进行存储的专用计算机。 2.4 C/S 模式 又称客户机/服务器模式，是指客户端需要安装专用的客户端软件来访问服务器的一种结构。 2.5 B/S 模式 又称浏览器/服务器结构，这种结构下用户使用界面是通过网页浏览器来实现的。3 组织机构及职责 3.1 行政部是公司生产实时数据库系统的归口管理部门，负责组织及制定生产实时数据库系统的管理制度，对生产实时数据库系统的日常运行维护及系统安全进行管理。 3.2 电仪维修部、硝区维修部负责协助行政部管理生产实时数据库系统，向行政部提供所需信息及资源，并配合处理数据库系统的应用和故障排查。 3.3 使用实时数据库系统的用户应按照各自使用权限正确安全的使用数据库客户端，负责向系统管理员反映系统使用中出现的各种问题。 4 数据服务器的管理 4.1 实时数据库系统使用的数据服务器日常操作维护由行政部系统管理员负责。 4.2 数据服务器、防火墙和网络通信设备是数据库系统的关键设备，必须放置在专用计算机机房内，不得随意配置或更换，更不能挪作它用。 4.3 放置数据服务器的计算机机房要保持清洁、卫生，并由系统管理员负责每月最少2次检查和维护，除系统维护时间外，要保障数据服务器24小时无故障运行。
MES 系统实时数据库的设计与实现 内容摘要:大连石化公司的生产运行系统 (MES 采用了 Honeywell 公司软件包实现的, PHD 实时数据库是生产运行系统(MES 的基础。本文介绍了 PHD 实时数据库的结构设计, 通过标准的 OPC 接口技术与 PHD 的 Buffer/Shadow技术结合完成了数据采集,满足了生产运行系统(MES 的总体目标。 关键词:生产运行系统(MES 、 PHD 实时数据库、集散控制系统(DCS 、 OPC 接口 1、前言 中国石油为了加快各业务领域的信息化建设, 2004年,生产运行系统(MES 列入股份公司年度信息技术项目计划, 最后选择了大连石化公司为试点单位, 开始进行试点实施工作。目前中国石油生产运行系统(MES 已经进入了第三期推广中,预计2009年底完成推广,大连石化公司试点的 MES 系统已于 2005年 12月份正式上线运行,目前运行稳定,为公司信息化建设奠定了基础。 2、 PHD 实时数据库的开放性 现代化炼厂大量采用了 DCS 等自动化仪表及控制设备进行生产过程、公用工程、罐区等自动化控制。 Honeywell 公司的实时数据库软件包具有与这些常用设备的接口和数据采集能力,而且该软件包具有接口软件的开发工具,以便为特殊设备开发接口。同时,还能采集非连续的数据,如实验室的分析数据,物料的移动数据等。PHD 实时数据库最终是供用户或应用程序使用的, PHD 实时数据库为用户提供了与外界进行数据传输的途径:API 函数库、 OPC 接口、 ODBC 和 SQL 接口、Automation OLE Server以及 ActiveX 控件等接口方式。 3、大连石化公司 PHD 数据库的设计方案 1 PHD 实时数据库设计目标 PHD 实时数据库应用平台不仅可以管理实时数据,还能进行事件信息、事务性数据和应用数据的管理,分别将相关测量值存放于过程实时数据库;将操作变化、报警信息、过程变化等事件存放于事件数据库;将物料移动记录、化验室分析数据、
实时数据库系统选型 目前国内外实时数据库分为四种类型：一种是国外传统实时数据库、国外组态软件供应商实时数据库、国内传统实时数据库和国内组态软件供应商实时数据库，下面分别介绍以上四种类型的实时数据库： （1）国外传统实时数据库包括： a. OSI公司的PI( Plant Information System ) b. Aspen公司的IP21( InfoPlus.21 ) c. Honeywell公司的PHD( Process History Database ) d. Instep公司的eDNA(enterprise Distributed Network Architecture) PI在国内广泛应用于电力行业，它采用了旋转门压缩专利技术和独到的二次过滤技术，使进入到PI数据库的数据经过了最有效的压缩，极大地节省了硬盘空间；IP21和PI一样属于正宗的实时数据库软件，价格和PI差不多，比较昂贵，IP21在中石油、中石化内部得到了广泛使用；由于Honeywell占据了化工行业DCS大部分份额，因此PHD在化工行业使用得也比较广泛，PHD在内部使用了Oracle关系数据库； 以上三种实时数据库均为二十世纪末推出来的传统实时数据库，由于在电力行业占垄断地位的PI价格居高不下，Instep eDNA凭借价格优势进入了电力行业，逐渐拥有了一定的客户，因此目前大型电力企业仍然偏爱OSI PI，不少中小电力企业则选择了eDNA。 特点：价格高、实时数据库包含实时数据库及其它配套软件。 （2）国外组态软件供应商实时数据库 a. Wonderware公司的Historian( 原InSQL) b. GE Fanuc公司的iHistorian c. Rockwell公司的RSSQL d. Siemens公司的SIMATIC-IT-Historian 由于Wonderware的组态软件Intouch在国内工控业界的普遍使用，尤其在钢铁行业的广泛使用，因此Wonderware Historian(原InSQL)在钢铁行业占有较大的市场，Wonderware Historian在内部使用了MS SQL Server关系数据库,相对前三种实时数据库，Wonderware Historian进入实时数据库市场较晚，相对易学
1. 物理层 在OSI参考模型中，物理层（Physical Layer）是参考模型的最低层，也是OSI模型的第一层。 物理层的主要功能是：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。需要注意的是，物理层并不是指连接计算机的具体物理设备或传输介质，如双绞线、同轴电缆、光纤等，而是要使其上面的数据链路层感觉不到这些差异，这样可使数据链路层只需要考虑如何完成本层的协议和服务，而不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的，当然，物理层并不需要知道哪几个比特代表什么意思。 为了实现物理层的功能，该层所涉及的内容主要有以下几个方面： （1）通信连接端口与传输媒体的物理和电气特性 λ机械特性：规定了物理连接器的现状、尺寸、针脚的数量，以及排列状况等。例如EIA-RS-232-D标准规定使用25根引脚的DB-25插头座，其两个固定螺丝之间的距离为47.04±0.17mm等。 λ电气特性：规定了在物理连接信道上传输比特流时的信号电平、数据编码方式、阻抗及其匹配、传输速率和连接电缆最大距离的限制等。例如EIA-RS-232-D标准采用负逻辑，即逻辑0（相当于数据“0”）或控制线处于接通状态时，相对信号的地线有+5～+15V的电压；当其连接电缆不超过15米时，允许的传输速率不超过20Kb/s。 λ功能特性：规定了物理接口各个信号线的确切功能和含义，如数据线和控制线等。例如EIA-RS-232-D 标准规定的DB-25插头座的引脚2和引脚3均为数据线。λ规程特性：利用信号线进行比特流传输时的操作过程，例如信号线的工作规则和时序等。 （2）比特数据的同步和传输方式 物理层指定收发双方在传输时使用的传输方式，以及为保持双方步调一致而采用的同步技术。例如在采用串行传输时，其同步技术是采用同步传输方式还是异步传输方式。（3）网络的物理拓扑结构 物理拓扑规定了节点之间外部连接的方式。例如星形拓扑、总线型拓扑、环形拓扑和网状拓扑等。 （4）物理层完成的其他功能 λ数据的编码。 调制技术。λ 通信接口标准。λ 2. 数据链路层 数据链路层（Data Link Layer）是OSI模型的第二层，负责建立和管理节点间的链路。该层的主要功能是：通过各种控制协议，将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。(交换机) 在计算机网络中由于各种干扰的存在，物理链路是不可靠的。因此，这一层的主要功能是在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路，即提供可靠的通过物理介质传输数据的方法。 该层通常又被分为介质访问控制（MAC）和逻辑链路控制（LLC）两个子层。MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题，完成网络介质的访问控制；LLC子层的主要任务是建立和维护网络连接，执行差错校验、流量控制和链路控制。 数据链路层的具体工作是接收来自物理层的位流形式的数据，并加工（封装）成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层；并且，还负责处理接收端发回的确认帧的信息，以便提供可靠的数据传输。数据链路层的主要功能如下： λ数据帧的处理：处理数据帧的封装与分解。 λ物理地址寻址：通过数据帧头部中的物理地址信息，建立源节点到目的节点的数据链路，并进行维护与释放链路的管理工作。 λ流量控制：对链路中所发送的数据帧的速率进 行控制，以达到数据帧流量控制的目的。 λ帧同步：对数据帧的传输顺序进行控制（即帧 的同步和顺序控制）。 λ差错检测与控制：通常在帧的尾部加入用于差 错控制的信息，并采用检错检测和重发式的差错控制技 术。例如处理接收端发回的确认帧。 3. 网络层 网络层（Network Layer）是OSI模型的第三层，它是OSI 参考模型中最复杂的一层，也是通信子网的最高一层。它 在下两层的基础上向资源子网提供服务。其主要任务是： 通过路由选择算法，为报文或分组通过通信子网选择最适 当的路径。该层控制数据链路层与传输层之间的信息转 发，建立、维持和终止网络的连接。具体地说，数据链路 层的数据在这一层被转换为数据包，然后通过路径选择、 分段组合、顺序、进/出路由等控制，将信息从一个网络 设备传送到另一个网络设备。 一般地，数据链路层是解决同一网络内节点之间的通信， 而网络层主要解决不同子网间的通信。例如在广域网之间 通信时，必然会遇到路由（即两节点间可能有多条路径） 选择问题。在实现网络层功能时，需要解决的主要问题如 下： λ寻址：数据链路层中使用的物理地址（如MAC 地址）仅解决网络内部的寻址问题。在不同子网之间通信 时，为了识别和找到网络中的设备，每一子网中的设备都 会被分配一个唯一的地址。由于各子网使用的物理技术可 能不同，因此这个地址应当是逻辑地址（如IP地址）。 λ交换：规定不同的信息交换方式。常见的交换 技术有：线路交换技术和存储转发技术，后者又包括报文 交换技术和分组交换技术。 λ路由算法：当源节点和目的节点之间存在多条 路径时，本层可以根据路由算法，通过网络为数据分组选 择最佳路径，并将信息从最合适的路径由发送端传送到接 收端。 λ连接服务：与数据链路层流量控制不同的是， 前者控制的是网络相邻节点间的流量，后者控制的是从源 节点到目的节点间的流量。其目的在于防止阻塞，并进行 差错检测。 4. 传输层 OSI下3层的主要任务是数据通信，上3层的任务是数据 处理。而传输层（Transport Layer）是OSI模型的第4 层。因此该层是通信子网和资源子网的接口和桥梁，起到 承上启下的作用。 该层的主要任务是：向用户提供可靠的端到端的差错和流 量控制，保证报文的正确传输。传输层的作用是向高层屏 蔽下层数据通信的细节，即向用户透明地传送报文。该层 常见的协议：TCP/IP中的TCP协议、Novell网络中的SPX 协议和微软的NetBIOS/NetBEUI协议。 传输层提供会话层和网络层之间的传输服务，这种服务从 会话层获得数据，并在必要时，对数据进行分割。然后， 传输层将数据传递到网络层，并确保数据能正确无误地传 送到网络层。因此，传输层负责提供两节点之间数据的可 靠传送，当两节点的联系确定之后，传输层则负责监督工 作。综上，传输层的主要功能如下： λ传输连接管理：提供建立、维护和拆除传输连 接的功能。传输层在网络层的基础上为高层提供“面向连 接”和“面向无接连”的两种服务。 λ处理传输差错：提供可靠的“面向连接”和不 太可靠的“面向无连接”的数据传输服务、差错控制和流 量控制。在提供“面向连接”服务时，通过这一层传输的 数据将由目标设备确认，如果在指定的时间内未收到确认 信息，数据将被重发。 λ监控服务质量。 5. 会话层 会话层（Session Layer）是OSI模型的第5层，是用户 应用程序和网络之间的接口，主要任务是：向两个实体的 表示层提供建立和使用连接的方法。将不同实体之间的表 示层的连接称为会话。因此会话层的任务就是组织和协调 两个会话进程之间的通信，并对数据交换进行管理。 用户可以按照半双工、单工和全双工的方式建立会话。当 建立会话时，用户必须提供他们想要连接的远程地址。而 这些地址与MAC（介质访问控制子层）地址或网络层的逻 辑地址不同，它们是为用户专门设计的，更便于用户记忆。 域名（DN）就是一种网络上使用的远程地址例如： https://www.doczj.com/doc/567081697.html,就是一个域名。会话层的具体功能如下： λ会话管理：允许用户在两个实体设备之间建 立、维持和终止会话，并支持它们之间的数据交换。例如 提供单方向会话或双向同时会话，并管理会话中的发送顺 序，以及会话所占用时间的长短。 λ会话流量控制：提供会话流量控制和交叉会话 功能。 寻址：使用远程地址建立会话连接。λ λ出错控制：从逻辑上讲会话层主要负责数据交 换的建立、保持和终止，但实际的工作却是接收来自传输 层的数据，并负责纠正错误。会话控制和远程过程调用均 属于这一层的功能。但应注意，此层检查的错误不是通信 介质的错误，而是磁盘空间、打印机缺纸等类型的高级错 误。 6. 表示层 表示层（Presentation Layer）是OSI模型的第六层，它 对来自应用层的命令和数据进行解释，对各种语法赋予相 应的含义，并按照一定的格式传送给会话层。其主要功能 是“处理用户信息的表示问题，如编码、数据格式转换和 加密解密”等。表示层的具体功能如下： λ数据格式处理：协商和建立数据交换的格式， 解决各应用程序之间在数据格式表示上的差异。 λ数据的编码：处理字符集和数字的转换。例如 由于用户程序中的数据类型（整型或实型、有符号或无符 号等）、用户标识等都可以有不同的表示方式，因此，在 设备之间需要具有在不同字符集或格式之间转换的功能。 λ压缩和解压缩：为了减少数据的传输量，这一 层还负责数据的压缩与恢复。 数据的加密和解密：可以提高网络的安全性。λ 7. 应用层 应用层（Application Layer）是OSI参考模型的最高层， 它是计算机用户，以及各种应用程序和网络之间的接口， 其功能是直接向用户提供服务，完成用户希望在网络上完 成的各种工作。它在其他6层工作的基础上，负责完成网 络中应用程序与网络操作系统之间的联系，建立与结束使 用者之间的联系，并完成网络用户提出的各种网络服务及 应用所需的监督、管理和服务等各种协议。此外，该层还 负责协调各个应用程序间的工作。 应用层为用户提供的服务和协议有：文件服务、目录服务、 文件传输服务（FTP）、远程登录服务（Telnet）、电子 邮件服务（E-mail）、打印服务、安全服务、网络管理服 务、数据库服务等。上述的各种网络服务由该层的不同应 用协议和程序完成，不同的网络操作系统之间在功能、界 面、实现技术、对硬件的支持、安全可靠性以及具有的各 种应用程序接口等各个方面的差异是很大的。应用层的主 要功能如下： λ用户接口：应用层是用户与网络，以及应用程 序与网络间的直接接口，使得用户能够与网络进行交互式 联系。 λ实现各种服务：该层具有的各种应用程序可以 完成和实现用户请求的各种服务。 8. 7层模型的小结 由于OSI是一个理想的模型，因此一般网络系统只涉及其 中的几层，很少有系统能够具有所有的7层，并完全遵循 它的规定。 在7层模型中，每一层都提供一个特殊的网络功能。从网 络功能的角度观察：下面4层（物理层、数据链路层、网 络层和传输层）主要提供数据传输和交换功能，即以节点 到节点之间的通信为主；第4层作为上下两部分的桥梁， 是整个网络体系结构中最关键的部分；而上3层（会话层、 表示层和应用层）则以提供用户与应用程序之间的信息和 数据处理功能为主。简言之，下4层主要完成通信子网的 功能，上3层主要完成资源子网的功能。 9. 建立OSI参考模型的目的和作用 建立OSI参考模型的目的除了创建通信设备之间的物理 通道之外，还规划了各层之间的功能，并为标准化组织和 生产厂家制定了协议的原则。这些规定使得每一层都具有 一定的功能。从理论上讲，在任何一层上符合OSI标准的 产品都可以被其他符合标准的产品所取代。因此，OSI参 考模型的基本作用如下： λ OSI的分层逻辑体系结构使得人们可以深刻地 理解各层协议所应解决的问题，并明确各个协议在网络体 系结构中所占据的位置。 λ OSI参考模型的每一层在功能上与其他层有着 明显的区别，从而使得网络系统可以按功能划分。这样， 网络或通信产品就不必面面俱到。例如，当某个产品只需 完成某一方面的功能时，它可以只考虑并遵循所涉及层的 标准。 λ OSI参考模型有助于分析和了解每一种比较复 杂的协议。 以后还会介绍其他参考模型或协议，例如TCP/IP、IEEE 802和X.25协议等，因此，还会比较它们与OSI模型的 关系，从而使读者进一步理解网络体系结构、模型和各种 协议的工作原理。
说到这个问题，基本上有人就会想到三个问题： 1，什么是系统数据？ 2，为什么要移动系统数据库？ 3，移动系统数据库我们可以用附加和分离，为什么还要单独拿出来说呢？ 对于这三个问题我一个一个讲吧，也算是自己做个笔记。 1，什么是系统数据？ 所谓系统数据库就是我们在装SQL Server之后，系统自带的数据库(这样的回答是不是很白痴^_^). 如果你装SQL Server2005或2008在打开一个SQL实例后，就会看到一个数据库--->系统数据库文件夹，里边就是系统自带的数据库，如图： 对于每一个系统数据库，这里我先用简单的语言说一下: 1)，master: 这个数据库是全局数据库，它包含一些系统表，权限分配，用户帐号设置，当前数据库配置信息以及关于磁盘空间，文件分配等信息。所以在执行诸如用户帐号设置，权限分配和改变系统配置信息后都要备份此数据。所以在这里强烈建议,不仅要经常备份自己的数据库，还有备份此数据库，虽然不像备份自己数据库那样那么频繁。至少半个月或一个月备份一次此数据库。 在这里还有专门的一个数据库大牛讨论过是否应该备份此数据库：SQL SERVER –Backup master Database Interval – master Database Best Practices 2)，model: 这个数据库只是一个模板数据库，我们在创建任意的一个数据库的时候，都是复制此数据库为新数据库的基础，如果希望每一个新的数据库都含有某些对象或者权限，
可以把这个对象或权限放在此数据库中，新创建的新数据库都会继承此数据的新对象或权限，并且拥有这些对象或权限。 3)，msdb: 作者原话：SQL Server代理服务器会使用该数据库，它会执行一些列如备份和复制任务的计划好的活动。Service Borker也会用到该数据库，他为SQL Sever提供队列和可靠消息传递。当我们不在该数据库执行备份或维护任务时，通常可以忽略该数据库。在SQL Server2005之前，实际上是可以删除该数据库的,只后SQL Server 仍然可用，但不能在维护任何备份历史了，并且不能够在定义任务，警告，工作或者建立复制，不过因为默认的msdb数据库非常小，建议即使用不到也不要删除它。 4)，tempdb: 该数据库说白了，就是一个中转站或数据寄存站，用户显示创建的临时表，在查询处理和排序时内部所产生的中间结果的工作表，维护用的快照等，都会用到此数据库，与其他数据库所不同的是，在每次SQL Server实例重启之后，都会重建而不是恢复. 所以我们在其中创建的所有对象和权限在下次重启SQL Server时都会全部丢失。 但是我们也不能忽略此数据库，因为tempdb的大小和配置，对优化SQL Server的功能和性能来说很重要。 对tempdb数据库，还要多说几句，虽然在tempdb每次被重建时，它会从model 数据库继承大多数的数据库选项，但是tempdb却不会从modeldb数据库中复制其恢复模式，因为它总是使用简单恢复模式。另外，tempdb是无法删除的，也不用备份。 2，为什么要移动系统数据库？ 我们在安装SQL Server后默认的这些系统数据库都会放在C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA此文件夹下，一般的都不很大，为什么我们还有移动他们呢？ 在没有实践管理服务器之前，我也没有这个想法，但是我发现我的服务器C盘一直都在增加，或者万一重装系统，我设置的数据库选项，以及用户账户设置都要重新设置，所以就有了这个想法。 还有一点就是作为重新布置计划或安排好的维护操作的一部分，我们也许需要移动系统数据库。 3，用附加和分离就可以，为什么还要单独说呢？ 回答这个问题之前，我们在看一张图
OSI七层模型各层分别有哪些协议及它们 的功能 在互联网中实际使用的是TCP/IP参考模型。实际存在的协议主要包括在：物理层、数据链路层、网络层、传输层和应用层。各协议也分别对应这5个层次而已。 要找出7个层次所对应的各协议，恐怕会话层和表示层的协议难找到啊。。 应用层 ·DHCP(动态主机分配协议) · DNS (域名解析） · FTP（File Transfer Protocol）文件传输协议 · Gopher （英文原义：The Internet Gopher Protocol 中文释义：（RFC-1436）网际Gopher协议）· HTTP （Hypertext Transfer Protocol）超文本传输协议 · IMAP4 (Internet Message Access Protocol 4) 即 Internet信息访问协议的第4版本· IRC （Internet Relay Chat ）网络聊天协议 · NNTP （Network News Transport Protocol）
RFC-977）网络新闻传输协议 · XMPP 可扩展消息处理现场协议 · POP3 (Post Office Protocol 3)即邮局协议的第3个版本 · SIP 信令控制协议 · SMTP （Simple Mail Transfer Protocol）即简单邮件传输协议 · SNMP (Simple Network Management Protocol,简单网络管理协议) · SSH （Secure Shell）安全外壳协议 · TELNET 远程登录协议 · RPC （Remote Procedure Call Protocol）（RFC-1831）远程过程调用协议 · RTCP （RTP Control Protocol）RTP 控制协议 · RTSP （Real Time Streaming Protocol）实时流传输协议 · TLS （Transport Layer Security Protocol）安全传输层协议 · SDP( Session Description Protocol）会话描述协议 · SOAP （Simple Object Access Protocol）