ITU-T Q 1400 ADD 1-1995 Architecture Framework for the Development of Signalling and OAM Protocols Using OSI Concepts - Intelligent Network (Study Group 11) 7 pp《信号和使用开放系统互连(OSI)的概.pdf

《ITU-T Q 1400 ADD 1-1995 Architecture Framework for the Development of Signalling and OAM Protocols Using OSI Concepts - Intelligent Network (Study Group 11) 7 pp《信号和使用开放系统互连(OSI)的概.pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 1400 ADD 1-1995 Architecture Framework for the Development of Signalling and OAM Protocols Using OSI Concepts - Intelligent Network (Study Group 11) 7 pp《信号和使用开放系统互连(OSI)的概.pdf（7页珍藏版）》请在麦多课文档分享上搜索。

1、INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU INTELLIGENT NETWORK Addendum 1 Q.1400 (02/95) ARCHITECTURE FRAMEWORK FOR THE DEVELOPMENT OF SIGNALLING AND OAM PROTOCOLS USING OS1 CONCEPTS Addendum 1 to ITU-T Recommendation Q.1400 (Previously “CCIlT Recomme

2、ndation”) FOREWORD The IT-T (Telecommunication Standardization Sector) is a permanent organ of the International Telecommunication Union (ITU). The -T is responsible for studying technical, operating and tariff questions and issuing Recommen- dations on them with a view to standardizing telecommunic

3、ations on a worldwide basis. The World Telecommunication Standardization Conference (WTSC), which meets every four years, establishes the topics for study by the -T Study Groups which, in their turn, produce Recommendations on these topics. The approval of Recommendations by the Members of the ITU-T

4、 is covered by the procedure laid down in WTSC Resolution No. 1 (Helsinki, March 1-12, 1993). Addendum 1 to IT-T Recommendation 4.1400 was prepared by ITU-T Study Group 11 (1993-1996) and was approved under the WTSC Resolution No. 1 procedure on the 7th of February 1995. NOTE In this Recommendation,

5、 the expression “Administration” is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. O ITU 1995 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including p

6、hotocopying and microfilm, without permission in writing from the IT. ITU-T RECMN*d*1400 ADDENDUM+L 95 = 4Bb259L Ob01083 20b Addendum 1 to Recommendation Q.1400 ARCHITECTURE FRAMEWORK FOR THE DEVELOPMENT OF SIGNALLING AND OAM PROTOCOLS USING OS1 CONCEPTS (Geneva, 1995) New rules on forward and backw

7、ard compatibility for protocols specified in ASN.l have been agreed. These rules are simple to use and are based on latest ASN.l, X.680-series Recommendations. Subclause 12.5/Q.1400 (1993) is to be replaced by the following text. 12.5 Compatibility rules for application layer protocols specified in

8、ASN.l It is envisaged that minor extensions to an application protocol may be needed from time to time. An abstract syntax is extended if its associated type is extended (e.g. if a choice type, it can be extended by adding a new component or extending an existing one). One way of extending a PDU (or

9、 any structure type) is to extend the type of any of its components. In supporting such extensions, care needs to be taken to ensure that the extensions are indeed minor. Therefore, the following types of extensions to the abstract syntax might be considered minor: - addition of an information eleme

10、nt which may enhance an activity but is not essential to performing the basic activity (e.g. list of additional routing options); or - addition of an information element to add a capability which is not essential to the base capability (e.g. addition of “Name” in addition to “Number” for terminal di

11、splay purposes). In the above cases, a new application context name need not be defined; however, forward compatibility procedures for dealing with the unknown information must exist at the receiving application process. The following types of extensions might be considered major: - - addition of a

12、new procedure; or fundamental alteration of a procedure (e.g. “do this procedure twice”). In these cases, a new application context name should be defined. Following backward and forward compatibility rules are applied to application layer protocols specified using ASN. 1. 12.5.1 Backward compatibil

13、ity des Modifications to all future versions of ITU-T Recommendations for ASN. 1 based signalling protocols from 1992 onwards shall be made in such a way that backward compatibility with older versions is ensured. The objective of the following subclauses is to provide guidelines on the types of cha

14、nges which can be made to a protocol specification while ensuring backward compatibility with the original protocol. Changes which do not affect the transfer-syntax (Le. the bits and bytes exchanged between peer entities) or which extend it are backward compatible. Using simple words, backward compa

15、tibility means that an encoded PDU of the original protocol is a valid encoded PDU for the new protocol. Apart from very specific cases, changes which do not affect the abstract syntax or extend it produce a backward- compatible transfer syntax when BER are employed. Such changes are listed in 12.5.

16、1.1 and 12.5.1.2. However, in the absence of forward compatibility rules, a proper interworking can only be ensured if extended values (i.e. values which belong to the extended abstract syntax but not to the original one) are never sent to an implementation which only supports the original protocol.

17、 Addendum 1 to Recommendation Q.1400 (02/95) 1 ITU-T RECMN*Q-1400 ADDENDUM*L 95 Y862591 Ob03084 142 Non-backward compatible changes are those which affect the transfer-syntax in a non-compatible way. In this case, an encoded PDU of the original protocol is not necessarily a valid encoded PDU for the

18、 new protocol. In general, a non-compatible change from an abstract-syntax point of view causes a non-compatible change from a transfer-syntax point of view. However, for a given set of encoding rules there may be some exceptions. An example for such changes are listed in 12.5.1.3. In addition it is

19、 obvious that changing the encoding rules causes in most cases incompatibility from a transfer-syntax point of view. 12.5.1.1 Changes without impact on the abstract-syntax These changes are purely restricted to the way the abstract syntax and the type used for its definition are specified. They do n

20、ot affect the set of values defined by the abstract syntax. Such changes may be needed to bring a specification in line with the niles stated in 12.5.1.2 and 12.5.1.3 of this (this list is not necessarily complete). a) In a set type or sequence type, replace the use of “COMPONENTS OF with direct inc

21、lusion of the equivalent components, or vice versa. b) In a choice type, replacing nested choice types with direct inclusion of each “NamedType” which appear in the “AlternativeTypeList”. c) Replace a type by a “typereference” representing the same type or vice versa. d) Replace a value by a “valuer

22、eference” representing it or vice versa: This includes replacing a “number” by a “valuereference”. e) Replace a type by an equivalent selection type or vice versa. f) Add or (if unused) remove one or more “NamedBit” from a bit string type. g) Add or (if unused) remove one or more “NamedNumber” from

23、an integer type. h) Change the spelling of a “typereference”, a “modulereference” a “valuereference” or an “identifier” consistently throughout all ASN. 1 modules. This includes adding identifiers where allowed from the syntax. i) Split up one ASN. 1 module into several ASN. 1 modules. j) Put severa

24、l ASN.l modules together into one ASN.l module. k) Move parts of one ASN. 1 module into another ASN. 1 module. 1) Add one or more “Symbol” to the “EXPORTS” list. (or remove the “EXPORTS” statement to indicate that everything is exported). m) Add one or more “Symbol” to the “IMPORTS” list (symbols fr

25、om ASN. 1 modules already referenced in the “IMPORTS” list as well as symbols from newly referenced ASN. 1 modules). n) Remove one or more existing “Valueassignment” if their associated “valuereference” is never used (even not implicitly in ANY DEFINED BY construction) throughout all ASN. 1 modules.

26、 o) Remove one or more existing Typeassignment” (including those of Type OPERATION and ERROR) if they are never used throughout all ASN.l modules. p) Add an ERROR Type or Value which was already included in the abstract syntax (Le. attached to another OPERATION type) to the list of ERRORS of an OPER

27、ATION Type if it had such a list or add a list of ERRORS to an OPERATION Type if it did not have a list. q) Add an OPERATION Type or Value which was already included in the abstract syntax (e.g. not as a linked Operation) to the list of LINKED OPERATIONS of an OPERATION Type if it had such a list or

28、 add a list of LINKED OPERATIONS to an OPERATION Type if it did not have a list. 2 Addendum 1 to Recommendation Q.1400 (0395) 12.5.1.2 Extension of an abstract syntax An abstract syntax is extended if its associated type is extended (i.e. if a choice type, it can be extended by adding a new componen

29、t or extending an existing one). One way of extending a PDU (or any structured type) is to extend the type of any of its components. One ASN.l type is considered to be an extension of another if the former includes ali the values of the latter and possibly some others. Given a certain type, its exte

30、nsions are those types which could be derived by one or more of the following changes, combined with any number of those described in 12.5.1.1. a) Change a single type into a choice type which includes this single type in the “AlternativeTypeList”. NOTE 1 - The tag of this alternative has to remain

31、unchanged, no additional (EXPLICIT) Tag is allowed. It has to be taken care, that all references to this changed type throughout all ASN.l modules still meet all ASN.l requirements - in particular distinctness of tags and uniqueness of identifiers. Add one/more “NamedType” to the “AlternativeTypeLis

32、t” of a choice type. b) NOTE 2 - See Note 1 for changing a single type into a choice type. c) d) e) f) g) Add an optional component to a sequence type or a set type. Add a default component to a sequence type or a set type. Extend one or more components of a choice type, sequence type or a set type.

33、 Extend the type in terms of which a sequence-of type or a set-of type is defined. Change a mandatory component of a sequence type or set type to an optional or default component. NOTE 3 - The Tag of this component has to remain unchanged and distinctness of Tags has to be ensured. h) Add one or mor

34、e new “NamedNumber” to an enumerated type. NOTE 4 - Distinctness of values and uniqueness of identifiers has to be ensured. i) Extend the “ValueRange” of an integer type by decreasing the “LowerEndpoint” and/or increasing the “UpperEndpoint” . Extend the “SizeConstraint” of an octet string type, a b

35、it string type or a character string type by decreasing the “LowerEndpoint” and/or increasing the “UpperEndpoint”. Extend the “SizeConstraint” of a sequence-of type or a set-of type by decreasing the “LowerEndpoint”: and/or increasing the “UpperEndpoint”. Change the “Value” assigned to a “valuerefer

36、ence” if the effect for all references still meets all other rules (e.g. increase a Value used only as “UpperEndpoint” in a “ValueRange” or “SizeConstraint”). The following changes to OPERATION and ERROR definition affect the abstract syntax formed by the set of values whose type is the one of TCAP

37、messages or ROSE PDUs parameterized by a specific list of operations. m) Add new value definition of Type OPERATION and ERROR respectively as long as they are distinct with all other value definitions of Type OPERATION and ERROR respectively. j) k) 1) n) Add a Type as ARGUMENTRARAMETER to an OPERATI

38、ON Type if it did not have an ARGUMENTFARAMETER. Add a Type as RESULT to an OPERATION Type if it had an empty RESULT or no RESULT. Add a Type as PARAMETER to an ERROR Type if it did not have a parameter. o) p) 12.5.1.3 Non-compatible changes Changes cause incompatibility from an abstract-syntax poin

39、t-of-view when a value of the original abstract syntax is not a valid value for the new abstract syntax. A non-compatible change to the type(s) in terms of which an abstract syntax is defined causes an incompatibility between the original abstract syntax and the new one. Addendum 1 to Recommendation

40、 Q.1400 (02195) 3 ITU-T RECMN*Q*1400 ADDENDUMsL 95 4862591 ObOLOBb TL5 The following list provides some examples of such non-compatible changes: - - replace a type by another type even if the tag remains the same; remove a type definition or a value definition referred either explicitly (IMPORTS) or

41、 implicitly (ANY DEFINED BY of TCAP); remove a “NamedType” from the “AlternativeTypeList” of a Choice type; remove a “NamedNumber” from the “Enumeration” of an enumerated type; restrict the “ValueRange” of an integer type; restrict the “SizeConstraint” of a string type; restrict the “SizeConstraint”

42、 of a sequence-of type; change the order of elements in the “ElementTypeList” of a sequence type; make any combination of the above changes to one or more components of a structured type. - - - - - - - 12.5.2 Forward Compatibility des Forward compatibility is most generally achieved through applicat

43、ion-context negotiation. However, in order to minimize the number of protocol fallback in the signalling network it will sometimes be necessary to define forward compatibility rules which allow a version of a protocol to accept protocol data units generated by a future version without having to prov

44、ide a new application-context-name. This feature is also necessary where application context negotiations is not supported, e.g. the optional dialogue portion of TC is not supported. If the protocol designer wishes to ensure that a value of a PDU of the new version of a protocol be (at least) always

45、 partly recognized by an implementation of an older version of this protocol, the following guidelines shall be followed: the new protocol version shall comply with the rules described in 12.5.1 (i.e. the new abstract syntax shall be an extension of the old one); the applicable encoding rules (which

46、 shall be unchanged) permit the unknown parts of the encoding to be delimited; extensibility rules shall be included in the specification of the original protocol. If the last Recommendation is not followed, the behaviour of a receiving entity is implementation dependent. It is recommended to restri

47、ct the use of the extensibility rules to: the addition of OPTIONAL and DEFAULT components in types derived from the SEQUENCE or SET the addition of bit assignment in types derived from the BIT STRING type (without extending the size constraint); the addition of alternatives to a CHOICE type, providi

48、ng that it does not correspond to a mandatory element of a higher structure; the addition of an enumerated values to an ENUMERATED type, providing that it does not correspond to a mandatory element of a higher structure. The protocol designer shall be aware that extensibility rules beyond those list

49、ed here (e.g. relaxing a size constraint or a value range, or extending a CHOICE type corresponding to a mandatory element) may require special care (e.g. specifying error codes to be used when an unrecognized information element is encountered) to avoid important functional errors. type; ) This is always ensured if the BER are employed. 4 Addendum 1 to Recommendation Q.1400 (0295) There are two basic ways of providing a specification of the extensibility rules: i) The specification includes a general statement which globally applies to any PDU of the protocol. This is illust