1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-0300245.2013 DIRECTORY SERVICE FOR TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN) AND SYNCHRONOUS OPTICAL NETWORK (SONET) As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance
2、the industrys most-pressing business priorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These pri
3、orities follow a fast-track development lifecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is th
4、e North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication C
5、ommission (CITEL). For more information, visit . AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in
6、the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and t
7、hat a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or
8、procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American Nati
9、onal Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The p
10、rocedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute.
11、 Notice of Disclaimer b) Application Process (AP); and c) Network Service Access Point (NSAP). This standard makes use of the following term defined in ITU-T Recommendation X.500 | ISO 9594-1: a) Directory. This standard makes use of the following terms defined in ITU-T Recommendation X.501 | ISO 95
12、94-2: a) Alias; b) Attribute; ATIS-0300245.2013 4 c) Attribute type; d) Attribute value; e) Directory Information Base (DIB); f) Directory Information Tree (DIT); g) (Directory) name; h) Directory schema; i) Directory System Agent (DSA); j) Directory User Agent (DUA); k) Distinguished Name (DN); l)
13、DIT structure Rule; m) Entry; n) Name; o) Object class; p) Relative Distinguished Name (RDN); q) Structural Object Class; r) Subordinate; and s) Superior. This standard makes use of the following terms defined in ITU-T Recommendation X.518 | ISO 9594-4: a) Chaining; and b) Referral. This standard ma
14、kes use of the following terms defined in ITU-T Recommendation X.525 | ISO 9594-9: a) Caching; b) Master DSA; c) Replicated area; d) Replication; and e) Shadowing. This standard makes use of the following terms defined in ITU-T Recommendation M.3010: a) Network Element (NE); and b) Operations System
15、 (OS). This standard makes use of the following term defined in ITU-T Recommendation X.701 | ISO/IEC 10040: a) Management Information Base (MIB). ATIS-0300245.2013 5 3.2 Additional Definitions 3.2.1 Directory Server (DS): The DS consists of a DSA and possibly other application processes, such as the
16、 Registration Manager defined in this standard, to provide the Directory Service with additional features such as automatic registration of a network element in a DIT. 3.2.2 local cache: The (optional) local cache is a copy of a subset of the DIB. Each Network Element may have a local cache containi
17、ng information on names and addresses of frequently used NEs. This helps reduce the query traffic from the NE with a DUA to the DSA. 3.2.3 MIB/DIB synchronization: MIB/DIB synchronization in Directory Services ensures that two semantically identical attributes in the Management Information Base and
18、the Directory Information Base have consistent values. The MIB/DIB synchronization algorithm ensures that updates to MIB object attributes result in updates to the paired DIB attribute. MIB/DIB synchronization is specified where applicable in the object class definitions of clause 9. 3.2.4 proxy age
19、nt: An agent that provides an application (e.g., management communication) on behalf of another system(s). Usage of the Directory Service by the proxy agent conforms to standard DSA access (i.e., via DAP by a DUA). 3.2.5 Registration Agent (RA): An RA is an application process that receives an RRP m
20、essage from the Registration Manager signaling it to start automatic registration. The result is that the R-NEs DUA adds the NE system administrative information (e.g., name, make, location, etc.) into the DIB via the “addEntry” operation of the DAP. The RA extracts the DS address from the RRP excha
21、nge and provides this address to the DUA. 3.2.6 Registration Manager (RM): An RM is an application process responsible for contacting the RA using the RRP to start automatic registration of a newly discovered NE into the DIB. The RM provides the RA with the appropriate DSA address. 3.2.7 Registratio
22、n Request Protocol (RRP): The RRP is the protocol used between the RM and RA for initiating automatic registration of an NE system administrative information in the DIB. 3.2.8 Remote-Network Element (R-NE): The R-NE is a type of NE that contains a DUA, an optional local cache, and possibly other app
23、lication processes such as the Registration Agent. The R-NE communicates with the DSA via the DAP. 4 Abbreviations ACSE Association Control Service Element AE Application Entity ANSI American National Standards Institute AP Application Process ASE Application Service Element ASN.1 Abstract Syntax No
24、tation One AVA Attribute Value Assertion B-DS Back-up Directory Server B-RM Back-up Registration Manager BLSR Bidirectional Line Switched Ring CCITT The International Telegraph and Telephone Consultative Committee DAP Directory Access Protocol DCN Data Communications Network ATIS-0300245.2013 6 DIB
25、Directory Information Base DIS Draft International Standard DISP Directory Information Shadowing Protocol DIT Directory Information Tree DN Distinguished Name DOP Directory Operational Binding Management Protocol DS Directory Server DSA Directory System Agent DSP Directory System Protocol DUA Direct
26、ory User Agent EM Element Manager ES End System IEC International Electrotechnical Commission IS Intermediate System ISO International Organization for Standardization ISP International Standardized Profile ITU-T International Telecommunication Union Telecommunication Standardization Sector IUT Impl
27、ementation Under Test LC Local Cache LCN Local Communications Network MD Mediation Device MHS Message Handling System MIB Management Information Base MF Mediation Function NE Network Element NEF Network Element Function NSAP Network Service Access Point OAM b) The selected object classes specified i
28、n clause 9 for which conformance is claimed; c) The selected attribute types specified in clause 10 for which conformance is claimed; and d) The selected abstract syntaxes and matching rules specified in clause 11 for which conformance is claimed. 5.2 Conformance by DSAs A DSA implementation claimin
29、g conformance to this Directory Service for TMN and SONET standard shall satisfy the requirements specified in 13.2 of ITU-T Recommendation X.519 on statement requirements, static requirements, and dynamic requirements that are relevant to the DSA functionality specified in clauses 7 through 14 of t
30、his standard, with the following additional requirements specific to TMN and SONET application. ATIS-0300245.2013 8 5.2.1 Additional Statement Requirements The following shall be stated: a) The selected structure rules and name forms specified in clauses 8 and G.4 for which conformance is claimed; b
31、) The selected object classes specified in clause 9 for which conformance is claimed; c) The selected attribute types specified in clause 10 for which conformance is claimed; and d) The selected abstract syntaxes and matching rules specified in clause 11 for which conformance is claimed. 5.2.2 Addit
32、ional Static Requirements A DSA shall: a) Have the capability of at least supporting the directoryAccessAC application-context as defined by its abstract syntax in clause 8 of ITU-T Recommendation X.519; b) Have the capability of supporting the structure rules and name forms specified in G.4 for whi
33、ch conformance is claimed; c) Have the capability of supporting the object classes specified in clause 9 for which conformance is claimed; d) Have the capability of supporting the attribute types specified in clause 10 for which conformance is claimed; and e) Have the capability of supporting the ab
34、stract syntaxes and matching rules specified in clause 11 for which conformance is claimed. 5.3 Conformance by RMs The optional Directory population feature is described in clause 13. A SONET environment that claims conformance to this standard shall support the Directory population feature. At leas
35、t one RM implementation is needed per OSI Level 1 routing area to support the Directory population feature. An RM implementation claiming conformance to this Directory Service for TMN and SONET standard shall satisfy the requirements specified below. a) Statement Requirements: The following shall be
36、 stated: the operations of the registrationApplicationContext application-context that the RM is capable of invoking for which conformance is claimed. b) Static Requirements: An RM shall have the capability of supporting the registrationApplicationContext application-context for which conformance is
37、 claimed as defined by their abstract syntax in G.5. c) Dynamic Requirements: An RM shall conform to the mapping onto ACSE and ROSE services as defined in clause 13. 5.4 Conformance by RAs The optional Directory population feature is described in clause 13. A SONET NE that claims conformance to this
38、 standard shall support the Directory population feature by supporting the RA functionality. An RA implementation claiming conformance to this Directory for TMN and SONET standard shall satisfy the requirements specified below: a) Statement Requirements: The following shall be stated: the operations
39、 of the registrationApplicationContext application-context for which conformance is claimed. b) Static Requirements: An RA shall support the registrationApplicationContext application-context for which conformance is claimed as defined by their abstract syntax in clauses 13 and G.5. ATIS-0300245.201
40、3 9 c) Dynamic Requirements: An RA shall conform to the mapping onto ACSE and ROSE services as defined in clause 13. 5.5 Conformance by a shadow supplier DSA A DSA implementation claiming conformance to this Directory Service in the role of shadow supplier shall satisfy the requirements specified in
41、 13.3 of ITU-T Recommendation X.519 on statement requirements, static requirements, and dynamic requirements that are relevant to the DSA functionality specified in clauses 7 through 14 of this standard. 5.6 Conformance by a Shadow Consumer DSA A DSA implementation claiming conformance to this Direc
42、tory Service in the role of shadow consumer shall satisfy the requirements specified in 13.4 of ITU-T Recommendation X.519 on statement requirements, static requirements, and dynamic requirements that are relevant to the DSA functionality specified in clauses 7 through 14 of this standard. 6 Require
43、ments Open systems that are participating in the TMN for the purposes of management require specific knowledge in order to determine the peer systems with which to associate, to enable association, and to fulfill their management functions. In addition, human users of the TMN need certain informatio
44、n to perform their functions. Some of this knowledge may be available from a Directory Service. The following subclauses describe specific requirements that can be satisfied by the Directory Service defined in this standard. 6.1 Naming/Addressing Support This Directory Service supports the determina
45、tion of: a) The TMN elements involved in the management subsystem; b) The identity of a Network Element or an Operations System based on its Network Address; c) The identity of an NE or an OS based on technology-, implementation-, network-, or operation-dependent naming (such as M.3100:userLabel) wh
46、ere available; d) The identity of NEs and OSs based on vendor or locality information, where known; e) The identity of an NE or an OS from its MIB naming attribute (M.3100:managedElementId); f) The value of the M.3100:managedElementId of an NE or an OS for use in management protocol exchanges; g) Th
47、e identity of an NE or an OS based on its function and role; h) The identity of a Bidirectional Line Switched Ring (BLSR) NE based on its ring node ID information; and i) The identity of an OS based on its additionally supported functional blocks, as defined in ITU-T Recommendation M.3010. 6.2 Assoc
48、iation Resolution This Directory Service supports the determination of: ATIS-0300245.2013 10 a) The Application Entity titles of the entities with which management associations may be established; b) The presentation addresses of those entities; and c) Given a managed object and optionally the name
49、of a desired management capability, the identity of one or more management agents capable of providing that management function.46.3 Shared Management Knowledge Managed objects may represent both static and dynamic resources. This Directory Service shall not be used to store dynamic state information which is obtainable from the MIB. Furthermore, the information in the DIB is updated only through abstract services. This Directory Service supports the determination of: 5a) The supported application contexts of a management application entity; b) The supported functional units of a manage
