ITU-T Y 1705 1 AMD 1-2006 Protocol for automatic discovery in SDH and OTN networks Amendment 1 New Appendix VI – Usage of the different discovery mechanisms (Study Group 15 Also kn.pdf

1、 International Telecommunication Union ITU-T G.7714.1/Y.1705.1TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 1(02/2006) SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS Data over Transport Generic aspects Transport network control aspects SERIES Y: GLOBAL INFORMATION

2、 INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Internet protocol aspects Operation, administration and maintenance Protocol for automatic discovery in SDH and OTN networks Amendment 1: New Appendix VI Usage of the different discovery mechanisms ITU-T Recommendation G.7714.1/

3、Y.1705.1 (2003) Amendment 1 ITU-T G-SERIES RECOMMENDATIONS TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100G.199 GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-TRANSMISSION SYSTEMS G.200G.299 INDIVIDUAL CHARACTERISTICS OF INT

4、ERNATIONAL CARRIER TELEPHONE SYSTEMS ON METALLIC LINES G.300G.399 GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC LINES G.400G.449 COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450G.499 TRANSMISSION MEDIA CH

5、ARACTERISTICS G.600G.699 DIGITAL TERMINAL EQUIPMENTS G.700G.799 DIGITAL NETWORKS G.800G.899 DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900G.999 QUALITY OF SERVICE AND PERFORMANCE GENERIC AND USER-RELATED ASPECTS G.1000G.1999 TRANSMISSION MEDIA CHARACTERISTICS G.6000G.6999 DATA OVER TRANSPORT GENERIC

6、 ASPECTS G.7000G.7999 General G.7000G.7099 Transport network control aspects G.7700G.7799 ETHERNET OVER TRANSPORT ASPECTS G.8000G.8999 ACCESS NETWORKS G.9000G.9999 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) i ITU-T Reco

7、mmendation G.7714.1/Y.1705.1 Protocol for automatic discovery in SDH and OTN networks Amendment 1 New Appendix VI Usage of the different discovery mechanisms Summary This new Appendix VI provides clarification of the network scenarios under which the various discovery mechanisms described in the mai

8、n body of this Recommendation may be utilized, including guidelines for usage of mechanisms and procedures as well as potential associated implications. Source Amendment 1 to ITU-T Recommendation G.7714.1/Y.1705.1 (2003) was agreed on 17 February 2006 by ITU-T Study Group 15 (2005-2008). ii ITU-T Re

9、c. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying te

10、chnical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups whic

11、h, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and

12、IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to

13、ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words do

14、es not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerni

15、ng the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by paten

16、ts, which may be required to implement this Recommendation. However, implementors are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. ITU 2006 All rights reserved. No part of this publication may be reproduced, by any

17、means whatsoever, without the prior written permission of ITU. ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) iii CONTENTS Page Amendment 1 New Appendix VI Usage of the different discovery mechanisms. 1 VI.1 Introduction 1 VI.2 Categories of Type 1 layer adjacency discovery use cases 1 VI.3 Use

18、 cases and scenarios 2 VI.4 Guidelines for mechanisms and procedures. 4 ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) 1 ITU-T Recommendation G.7714.1/Y.1705.1 Protocol for automatic discovery in SDH and OTN networks Amendment 1 New Appendix VI Usage of the different discovery mechanisms VI.1 I

19、ntroduction This appendix provides clarification of the network scenarios under which the various discovery mechanisms described in the main body of this Recommendation may be utilized, including guidelines for usage of mechanisms and procedures as well as potential associated implications. VI.2 Cat

20、egories of Type 1 layer adjacency discovery use cases The auto-discovery use cases can be subdivided into the categories depicted in Figure VI.1, i.e., Pre-Service, In-Service and Out-of-Service. Within the context of this Recommendation the terms: Pre-Service, In-Service and Out-of-Service are defi

21、ned as follows: Pre-Service: The entity that is in a pre-service state is the trail whose associated client link connections have not been allocated. As a consequence, operations will not impact any traffic. Pre-service includes scenarios where discovery is done immediately after a fault has been cl

22、eared and before service is considered restored (e.g., during soaking interval). In-Service: The entity that is in an in-service state is the trail whose associated client link connections have been allocated (one or more). Out-of-Service: The entity that is in an out-of-service state is the trail w

23、here all allocated client link connections are in a failed or non-usable state. This appendix only addresses auto-discovery use cases where the applied auto-discovery mechanism may cause some behavioural problems in the network, i.e., in-service case. The pre-service and out-of-service use cases, dr

24、awn with dotted lines in Figure VI.1, are not further discussed. Moreover, Type 2 LAD is also not considered because the link connections (LCs) cannot be in service (i.e., carry traffic) at the same time when Type 2 LAD is applied (see ITU-T Rec. G.7714/Y.1705 for the definition of Type 1 and Type 2

25、 LAD). Figure VI.1/G.7714.1/Y.1705.1 Categorization of discovery scenarios 2 ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) VI.3 Use cases and scenarios The various use cases where Type 1 layer adjacency auto-discovery (LAD) can be applied are described in this clause and guidelines are provide

26、d in VI.4 that explain how discovery can be accomplished based on the constraints imposed by the different scenarios. As specified in the main body of this Recommendation, it is assumed that there is always congruency between the signal being used for layer adjacency discovery and the entity being d

27、iscovered. In describing the various scenarios we broadly distinguish between two cases: a) the case where all the Network Elements (NEs) are auto-discovery capable; and b) the case where some of the NEs within the network are not auto-discovery capable. VI.3.1 All NEs are auto-discovery capable (ub

28、iquitous deployment) Ubiquitous deployment means that all NEs are auto-discovery capable and it is assumed that all involved NEs support LAD as defined in ITU-T Rec. G.7714/Y.1705 and in the main body of this Recommendation respectively. For this subset of cases one can use either trail-trace-based

29、or ECC-based discovery messages, provided all the NEs agree on a specific common mechanism. VI.3.2 All NEs are not auto-discovery capable In this case some of the NEs within the network are assumed to be unable to understand the auto-discovery messages (e.g., legacy equipment). We consider two scena

30、rio classes for the case where auto-discovery is being performed at a particular layer between the two NEs that represent the endpoints of that layer: scenarios where both NEs are LAD-capable; scenarios where one of the two NEs does not support LAD. VI.3.2.1 Auto-discovery between LAD-capable NEs As

31、 described in ITU-T Rec. G.7714/Y.1705, the LAD process requires that two NEs that are performing layer adjacency discovery must be immediate neighbors with respect to the layer where discovery is taking place (e.g., for SDH at RS, MS, HO or LO path layer). It is not possible, for example, to perfor

32、m LAD based on using the section trail trace (J0), RS DCCs, or MS DCCs when there is a NE between the two LAD-capable NEs that does not support LAD and terminates the regenerator and multiplex sections (RS and MS). Therefore, it is only possible to perform LAD at the path layer for such a configurat

33、ion and the HOVC path-trace (J1)-based discovery method may have to be used. This is illustrated in Figure VI.2. It is also possible for the network management system to run the HO path layer LAD process by proxy for the NEs, as depicted in Figure VI.3. ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/

34、2006) 3 Figure VI.2/G.7714.1/Y.1705.1 Immediate discovery-capable neighbours at HO path layer LAD done by NEs Figure VI.3/G.7714.1/Y.1705.1 Immediate discovery-capable neighbours at HO path layer LAD done by NMS 4 ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) VI.3.2.2 Auto-discovery between a

35、LAD-capable NE and a non-LAD-capable NE In this case we make the assumption that the non-LAD-capable NE terminates the layer being discovered (see Figure VI.4). In such a case, layer adjacency discovery cannot be performed at that specific layer since the discovery messages sent by the LAD-capable N

36、E are not understood by the non-LAD-capable NE. In such a scenario it is important that the non-LAD-capable NE does not generate alarms and, more important, not perform consequent actions that could unnecessarily disrupt service. One possible means for the network operator to avoid such alarms and c

37、onsequent actions is to disable the transmission of discovery messages at the LAD-capable NE or to obey the guidelines as described in VI.4. Figure VI.4/G.7714.1/Y.1705.1 Discovery-capable NE trying to discover a non-discovery-capable NE VI.4 Guidelines for mechanisms and procedures This clause prov

38、ides guidelines on the usage of the trail trace (J0, J1 and J2) and ECC (MS DCC or RS DCC) mechanisms for LAD for the various use cases and scenarios described in VI.3. VI.4.1 ECC-based LAD Auto-discovery using the DCC is a viable option when the DCC is available on the STM-n interface that needs to

39、 be discovered. The DCC provides a packet-based interface; its use for LAD is not affected by the service state (in-service, out-of-service, pre-service) of the given STM-n interface it is associated with. The LAD process making use of the DCC does not have any impact on the traffic on the STM-n int

40、erface. However, there are a number of use cases where the DCC may not be sufficient for LAD, based on DCC availability given the DCN deployment scenarios described below. VI.4.1.1 DCN deployment scenarios impacting the availability of DCCs There are two scenarios which affect the deployment of DCC-

41、based LAD messages: a) No DCC connectivity (e.g., Central Office LAN supporting the DCN). In this scenario, there is no DCC connectivity between the ADMs and the DXC in the Central Office (CO). Instead, as shown in Figure VI.5, the CO LAN is used to carry the ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.

42、1 (02/2006) 5 management communication between the Network Elements in the CO. Although there is connectivity (e.g., STM-n) between the ADMs and the DXC, the management communication does not follow the same topology as these optical connections that contain the DCCs. The DXC could be used to inter-

43、connect low-speed optical interfaces between ADMs within a CO and therefore the DCC on these low-speed optical interfaces are not available for auto-discovery. Figure VI.5/G.7714.1/Y.1705.1 Central Office with disabled DCC connectivity b) Limited DCC availability or DCCs not enabled on all parallel

44、interfaces between two NEs. In this scenario, as depicted in Figure VI.6, there may be limited or no DCC availability for management communication between Network Elements e.g., due to disabling of DCCs, or limited DCC resources. This could occur between multiple carriers, at a customer-to-carrier i

45、nterface, or where only out-of-band connectivity is available between the NEs and therefore the DCC is not available for auto-discovery. It is also possible that there are multiple parallel optical interfaces connecting the two NEs. However, the DCCs on only one link or a small subset of links may b

46、e enabled. This may be the case for several administrative reasons, e.g.: DCC processing not supported for all interfaces; configuration decision (e.g., in case of multiple parallel links, the DCCs are only enabled on some of them since the capacity of a single DCC may be sufficient for management c

47、ommunication between the two NEs); policy decisions in the case of connectivity of NEs between different administrative domains. In all these cases it may not be possible to perform LAD on every link using DCC because some of the links may not have the DCC enabled. Figure VI.6/G.7714.1/Y.1705.1 Cent

48、ral Office with DCC enabled on only one link or using an out-of-band DCN 6 ITU-T Rec. G.7714.1/Y.1705.1 (2003)/Amd.1 (02/2006) VI.4.2 Trail-trace-based LAD (e.g., using J0, J1 and J2 bytes) The trail-trace bytes can be utilized for Type 1 LAD, which allows one to infer the client layer LCs from the

49、discovered server layer trail as depicted in Figure 1/G.7714.1/Y.1705.1. Depending on the configuration of the trail termination functions involved in the LAD process, some behavioural issues could arise. In particular, traffic impact has to be avoided while the interfaces are in the in-service state and are carrying traffic. These scenarios where such behavioural issues might occur are addressed in this clause and are discussed in detail below. Moreover, application and configuration guidelines are provided in or