ITU-T Y 1713-2004 Misbranching detection for MPLS networks (Study Group 13)《MPLS网络的分路丢失检测 系列Y 第13研究组》.pdf

1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Y.1713TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2004) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT GENERATION NETWORKS Internet protocol aspects Operation, administration and maintenance Misbranching detection

2、for MPLS networks ITU-T Recommendation Y.1713 ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT GENERATION NETWORKS GLOBAL INFORMATION INFRASTRUCTURE General Y.100Y.199 Services, applications and middleware Y.200Y.299 Network aspects Y.300Y.399 Inte

3、rfaces and protocols Y.400Y.499 Numbering, addressing and naming Y.500Y.599 Operation, administration and maintenance Y.600Y.699 Security Y.700Y.799 Performances Y.800Y.899 INTERNET PROTOCOL ASPECTS General Y.1000Y.1099 Services and applications Y.1100Y.1199 Architecture, access, network capabilitie

4、s and resource management Y.1200Y.1299 Transport Y.1300Y.1399 Interworking Y.1400Y.1499 Quality of service and network performance Y.1500Y.1599 Signalling Y.1600Y.1699 Operation, administration and maintenance Y.1700Y.1799 Charging Y.1800Y.1899 NEXT GENERATION NETWORKS Frameworks and functional arch

5、itecture models Y.2000Y.2099 Quality of Service and performance Y.2100Y.2199 Service aspects: Service capabilities and service architecture Y.2200Y.2249 Service aspects: Interoperability of services and networks in NGN Y.2250Y.2299 Numbering, naming and addressing Y.2300Y.2399 Network management Y.2

6、400Y.2499 Network control architectures and protocols Y.2500Y.2599 Security Y.2700Y.2799 Generalized mobility Y.2800Y.2899 For further details, please refer to the list of ITU-T Recommendations. ITU-T Rec. Y.1713 (03/2004) i ITU-T Recommendation Y.1713 Misbranching detection for MPLS networks Summar

7、y This Recommendation provides mechanisms for user-plane OAM (Operation and Maintenance) functionality in MPLS networks to augment ITU-T Rec. Y.1711 according to the requirements and principles given in ITU-T Rec. Y.1710. The current version of this Recommendation is designed primarily to support po

8、int-to-point and multipoint-to-point LSPs independent of the method of establishment. Source ITU-T Recommendation Y.1713 was approved on 15 March 2004 by ITU-T Study Group 13 (2001-2004) under the ITU-T Recommendation A.8 procedure. Keywords Defect, failure, MPLS, OAM. ii ITU-T Rec. Y.1713 (03/2004)

9、 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 technical, operating and tariff questions and

10、 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 which, in turn, produce Recommendations on thes

11、e 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 IEC. NOTE In this Recommendation, the expre

12、ssion “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 ensure e.g., interoperability or applicabil

13、ity) 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 does not suggest that compliance with the Re

14、commendation 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 concerning the evidence, validity or applicability

15、 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 patents, which may be required to implement thi

16、s 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 2004 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior writte

17、n permission of ITU. ITU-T Rec. Y.1713 (03/2004) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Bibliography . 1 4 Definitions 2 5 Abbreviations 3 6 Applicability and overview of functionality. 3 7 Identification of OAM packets from normal user-plane traffic 4 8 OAM payload . 4 9 Handling of errored

18、OAM packets . 4 10 FEC connectivity verification. 4 11 Defect type codepoints . 5 12 CV and FEC-CV source and sink processing. 5 13 FEC-CV processing at intermediate LSRs . 6 14 Common encoding rules. 6 15 Egress processing . 8 16 Coding and processing rules for RFC 3036 (LDP) LSPs. 10 17 Coding and

19、 processing rules for RFC 3209 (RSVP-TE) LSPs 11 18 Coding and processing rules for RFC 3212 (CR-LDP) LSPs 12 19 Polynomial specification 12 20 Entry/Exit criteria and consequent actions . 13 21 Security aspects 14 Appendix I Coding and processing rules for RFC 2547 (BGP/VPN) LSPs 15 I.1 Scenario 1:

20、 Aggregated label LSP 15 I.2 Scenario 2: Non-aggregated label LSPs . 15 Appendix II Use of FEC-CV to check connectivity and measure route availability. 16 Appendix III Setting TFEC-CV 17 Appendix IV Issues with ECMP 18 Appendix V Issues with PHP. 21 ITU-T Rec. Y.1713 (03/2004) 1 ITU-T Recommendation

21、 Y.1713 Misbranching detection for MPLS networks 1 Scope This Recommendation provides mechanisms for user-plane OAM (Operation and Maintenance) functionality in MPLS networks according to the requirements and principles given in ITU-T Rec. Y.1710. The current version of this Recommendation is design

22、ed primarily to support point-to-point and multipoint-to-point LSPs independent of the method of establishment. The detection mechanism utilizes an additional OAM packet (known as FEC-CV) which uses protocol conventions in common with ITU-T Rec. Y.1711 (use of OAM alert label, the ITU-T Rec. Y.1711

23、administered PDU and code points). Usage and applicability is outlined in clause 6. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions i

24、ndicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-

25、T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. 1 ITU-T Recommendation Y.1711 (2004), Operation and ii) unmonitored LSPs where the egress does not have knowledge of the ingre

26、ss access point TTSI. Common usage is to bind single FEC elements to LSPs; however, the FEC-CV PDU will support multiple FEC elements for those operators that choose to use multiple FEC elements per LSP. The fixed length encoding has practical limits with respect to the number of FEC elements that c

27、an be encoded in a single probe (which are outlined in the coding and processing rules clauses of this Recommendation). It is assumed that an LSR offering multiple FEC per label bindings will use multiple labels when required to offer more FECs than can usefully be encoded in a single FEC-CV PDU. 7

28、Identification of OAM packets from normal user-plane traffic This Recommendation uses the globally reserved label value, herein referred to as the OAM Alert Label defined in 8 and ITU-T Rec. Y.1711 1. 8 OAM payload OAM payload is as per ITU-T Rec. Y.1711. 9 Handling of errored OAM packets Handling o

29、f errored OAM packets is as per ITU-T Rec. Y.1711. 10 FEC connectivity verification The FEC Connectivity Verification (FEC-CV) function may be used in place of the CV when additional or alternate defect detection capability is required, in particular detecting problems with the ingress FTN or proble

30、ms with other associated configuration information bound to the LSP. In this regard, the FEC-CV may be used on LSPs exclusively for the purpose of detecting FTN/configuration problems or may be combined with other sink processing functions to add FTN and/or configuration defects to the set of defect

31、s for which monitoring is performed. FEC-CV and CV may not be used interchangeably, the LSP ingress is configured to use one OR the other, not both. The LSP egress will treat receiving an unexpected function type as a dTTSI/FEC_Mismerge or dTTSI/FEC_Mismatch defect depending on the near end processi

32、ng function. The FEC-CV payload structure is similar to the CV payload structure with inclusion of the Bloom Filter termed the “FEC Filter“. The FEC Filter is an unstructured octet array. Function Type (08 hex) Reserved (all 00 hex) LSP Trail Termination Source Identifier (TTSI), 16 octets v6 LSN ID

33、 + 4 octets LSP tunnel ID FEC filter Padding (all 00 hex) BIP-16 1 octet 3 octets 20 octets 16 octets 2 octets 2 octets Figure 1/Y.1713 FEC-CV payload structure ITU-T Rec. Y.1713 (03/2004) 5 FEC-CV probes are inserted into LSPs at a configurable rate (TFEC-CV). Implementations should, as a minimum,

34、support insertion rates ranging from one every second to one per minute and may permit longer insertion intervals. 11 Defect type codepoints Defect type DT code (hex) Meaning dFECfilter_Mismatch 02 05 dFECfilter_Mismatch is due to unexpected FEC filter observed in the incoming FEC-CV OAM packets OR

35、due to unexpected Y.1711 CV or FFD OAM packet. Note that dFECfilter_Mismatch takes precedence over dLOCV defect condition which is also present. dFECfilter_Mismerge 02 06 dFECfilter_Mismerge is due to both unexpected and expected FEC filter observed in incoming FEC-CV OAM packet OR due to unexpected

36、 Y.1711 CV or FFD OAM packet received with expected FEC-CV OAM packet. 12 CV and FEC-CV source and sink processing CV, FFD_CV and FEC-CV source generation and CV/FFD-CV/FEC-CV sink processing should be considered as independent functions. This functional decoupling allows operators the flexibility t

37、o use different degrees of LSP monitoring on a per LSP basis, e.g., say between those LSPs deemed as important and those LSPs deemed less-important, or between LSPs that full defect processing and availability measurements can be performed on and those on which only a subset of defect detection can

38、be implemented on by reason of the control plane used (e.g., LDP). CV and FEC-CV generation is a relatively trivial function (since it never varies) and is much simpler than CV/FEC-CV sink processing. Each form of CV has specific applicability and usage in the network can be configured in a compleme

39、ntary fashion. The expected usage is that CV is generated on P2P LSPs that have no requirement for FTN verification, and FEC-CV is used for P2P LSPs requiring FTN verification and with LSPs signalled via the use of the LDP protocol. Hence, CV OR FEC-CV generation could be enabled on all (or most) of

40、 the LSPs. The sink processing for CV could be decomposed into several degree classes per LSP such as: 1) No CV processing. Hence no defect processing, no availability measurements and no QoS measurements. 2) A simple check of CV arrivals for unexpected function type (e.g., FEC_CV) but without exami

41、ning the TTSI (though it is assumed the TTSI is still generated). This cannot provide totally reliable connectivity verification since it cannot detect certain defects, and only provides partial detection of dMismerge/dMismatch. 3) Only a very simple check for arrival of CV packets with an unexpecte

42、d TTSI or unexpected function type (FEC-CV). This could be used on less important LSPs as a simple method for detecting leakage of important LSP traffic (into the less important LSP). However, there might be no other defect processing done (e.g., dLOCV) and no availability measurements. 4) Full defe

43、ct processing but no availability measurements. Note that if availability measurements are not being done, then QoS measurements are also strictly not possible (since these should only relate to when the LSP is in the available state). 5) Full defect processing and availability measurements (this no

44、w also allows the option of QoS measurements too). 6 ITU-T Rec. Y.1713 (03/2004) Similarly the sink processing for FEC-CV could be decomposed into several degree classes per LSP: 1) No FEC-CV processing. Hence no defect processing, no availability measurements and no QoS measurements. 2) A simple ch

45、eck of FEC-CV arrivals including unexpected function type (e.g., CV) without examining the FEC Filter or TTSI (though it is assumed that both are still generated). This cannot provide totally reliable connectivity verification since it cannot detect most defects, and only provides partial detection

46、of dMismerge/dMismatch. 3) Only a very simple check for arrival of FEC-CV packets with an unexpected function type or unexpected FEC Filter1. This could be used on LDP LSPs as a simple method for detecting leakage or FTN misconfiguration. 4) Full defect processing (including verification of both the

47、 FEC Filter and TTSI) but no availability measurements. Note that if availability measurements are not being done, then QoS measurements are also strictly not possible (since these should only relate to when the LSP is in the available state). 5) Full defect processing (including verification of bot

48、h the FEC Filter and TTSI) and availability measurements (this now also allows the option of QoS measurements too). 13 FEC-CV processing at intermediate LSRs FEC-CV PDUs normally are transferred by intermediate LSRs without inspection. LSRs inserting FEC-CV may choose to use manipulation of TTL valu

49、es to limit the number of hops traversed by an FEC-CV probe and therefore probes may terminate at intermediate LSRs. When an FEC-CV probe terminates at an intermediate LSR due to a TTL exhaust condition and is associated with a valid LSP, the LSR will only perform a check for the dFECfilter_Mismerge or dFECfilter_Mismatch defect conditions. When such a defect is detected at an intermediate LSR, the defect state is only considered to apply to the portion of the LSP that is upstream from the detecting LSR. This would translate to suppres