ITU-T Y 1711-2004 Operation and maintenance mechanism for MPLS networks (Study Group 13)《MPLS网络的AOM机制 系列Y 第13研究组》.pdf

《ITU-T Y 1711-2004 Operation and maintenance mechanism for MPLS networks (Study Group 13)《MPLS网络的AOM机制 系列Y 第13研究组》.pdf》由会员分享，可在线阅读，更多相关《ITU-T Y 1711-2004 Operation and maintenance mechanism for MPLS networks (Study Group 13)《MPLS网络的AOM机制 系列Y 第13研究组》.pdf（36页珍藏版）》请在麦多课文档分享上搜索。

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

2、 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-T Recommendations is regularly published. The reference to a document within this Recommendation doe

3、s not give it, as a stand-alone document, the status of a Recommendation. 2.1 Normative references 1 ITU-T Recommendation I.610 (1999), B-ISDN operation and maintenance principles and functions. 2 ITU-T Recommendation G.805 (2000), Generic functional architecture of transport networks. 3 ITU-T Recom

4、mendation M.20 (1992), Maintenance philosophy for telecommunication networks. 4 ITU-T Recommendation Y.1710 (2002), Requirements for Operation or ii) the LSP terminating LSR for all MPLS layer defects. ITU-T Rec. Y.1711 (02/2004) 5 BDI: The BDI flow is injected on a return path (such as a return LSP

5、) to inform the upstream LSR (which is the source of the forward LSP) that there is a defect at the downstream LSPs LSR sink point. BDI therefore tracks FDI in terms of its period of generation. BDI packets may be useful in 1:1/N instances of protection switching. Performance: These are FFS. However

6、, the intention is to have an on-demand method of determining packet/octet loss on an LSP in order to aid trouble-shooting. They are not intended to be used as a temporally permanent OAM function (unlike the CV flow), but they could be. Note that path trace, performance monitoring and loopback funct

7、ions are FFS. BDI and loopback transactions use a return path. A return path could be: A dedicated return LSP; A shared return LSP, which is shared between many forward LSPs; A non-MPLS return path, such as an out-of-band IP path. This option has potential security issues. For example, the return pa

8、th could be terminated on a different LSR interface, and potentially a malicious user could generate a BDI and send it to the ingress LSR. Therefore, due to the possibility of DoS attack, additional security measures must be taken. Operators should use the optional TTSI field in BDI packets in order

9、 to assure authentication of such packets so that the receivers of BDI OAM packets may verify that the sender of the packet is valid. All OAM packets are identified within a LSP traffic stream by the use of globally well-known and reserved label codepoint (of 14). Further details on the encoding of

10、OAM packets are provided later. It is strongly recommended that CV OAM or FFD OAM packets be generated on each LSP (in order to detect all defects and potentially provide protection against traffic leakage both in and out of LSPs). It is also recommended that FDI OAM packets be used to suppress alar

11、m storms. BDI packets are a useful tool for single-ended monitoring of both directions and also, in some protection-switching cases. However, these are only recommendations, and operators can choose to use some or all of the OAM packets as they see fit. Appendix I discusses some of the options for g

12、enerating and processing CV flows. OAM techniques are applied on a per LSP basis. If a segment of a given LSP at layer N is to be monitored for some reason (e.g., via a CV or P flow say), one way to do this is by creating a new server layer LSP (i.e., at layer N + 1) to cover the segment at layer N.

13、 5.1 Overview of functionality The OAM defect detection function is based on the periodic transmission of CV or FFD packets from ingress to egress of an LSP. CV packet generation rate is 1 packet per second whereas recommended packet generation rate for FFD packets is 20 per second. Each CV and FFD

14、packet carries a unique TTSI (Trail Termination Source Identifier), which is composed of the source LSR identifier, and the LSP identifier. An LSP enters a defect state when one of the defects noted in clause 3 occurs (these are defined in detail later in terms of precise entry/exit criteria and con

15、sequent actions). In addition to the CV packet, there are other OAM packet types defined that provide consequential fault handling or performance monitoring functions. These will be defined later. All OAM packets are identified in terms of a function type by the first octet of the OAM packet payload

16、 as follows (see Table 1): 6 ITU-T Rec. Y.1711 (02/2004) Table 1/Y.1711 OAM function type codepoints OAM function type codepoint (Hex) First octet of OAM packet payload function type and purpose 00 Reserved 01 CV (Connectivity Verification) 02 FDI (Forward Defect Indicator) 03 BDI (Backward Defect I

17、ndicator) 04 Reserved for Performance packets 05 Reserved for LB-Req (Loopback Request) 06 07 Reserved for LB-Rsp (Loopback Response) FFD (Fast Failure Detection) All other OAM Function Type codepoints are reserved for possible future standardization. 5.2 Identification of OAM packets from normal us

18、er-plane traffic The label structure defined in 6 indicates a single label field of 20 bits. Some label field values have already been reserved for special functions 6. This Recommendation introduces a new globally reserved label value, herein referred to as the “OAM Alert Label“. The recommended nu

19、merical value for the OAM Alert Label is 14 11. 5.3 OAM payload The payload of an OAM packet is composed of the OAM Function Type, the specific OAM function type data and a common BIP16 error detection mechanism. All OAM packets must have a minimum payload length of 44 octets to facilitate ease of p

20、rocessing and to support minimum packet size requirements of current L2 technologies (e.g., Ethernet). This is achieved by padding the specific OAM type data field with all 0s when necessary. All padding bits are reserved for possible future standardization. The order of transmission is from left to

21、 right, most significant bit (MSB) to least significant bit (LSB). 5.4 Handling of errored OAM packets Each OAM packet uses a BIP16 (in the last two octets of the OAM payload area) to detect errors. The BIP16 remainder is computed over all the fields of the OAM payload, including the Function Type a

22、nd the BIP16 bit positions (which are all pre-set to zero for initial calculation purposes). The BIP16 generator polynomial is G(x) = x16+ 1. BIP16 processing must be performed on all OAM packets prior to being able to reliably pass their payload for further processing. Any OAM packets that show a B

23、IP16 violation upon reception processing should be discarded. In the case of the CV or FFD packet flow, persistent BIP16 violations will cause a Loss of Connectivity Verification (dLOCV). This behaviour is consistent with the nature of the actual defect being experienced. However, it is recommended

24、that at a local equipment level some notification is given to the Network Management System to indicate when any BIP16 discards are occurring, especially if these give rise to an associated dLOCV. ITU-T Rec. Y.1711 (02/2004) 7 In the case of the other OAM packet types, i.e., the FDI, BDI and P packe

25、ts, it is again recommended that at a local equipment level, some indication is given to the Network Management System that BIP16 discards are occurring. The threshold to be used for recording/reporting such BIP16 discard activity for these OAM packets should be programmable, and is outside the scop

26、e of this Recommendation. 5.5 Engineering cost/risk considerations Operators must consider the impact of OAM functions on nodal processing resources and network traffic overhead vs an ability to detect all MPLS user-plane failures. In the case of the CV or FFD OAM packet, which forms the basis for d

27、efect detection, a clear distinction can be made between the source generation implications and the sink processing implications. This aspect is further discussed in Appendix I. 5.6 Backward compatibility considerations LSRs that do not support OAM functionality will drop OAM packets (because the OA

28、M Alert Label is not recognized) and therefore will not have an adverse impact on user-plane traffic. 6 OAM mechanisms 6.1 Features common to all OAM packets Some fields in the OAM packet header have a common treatment in all OAM packets. These are explained below. 6.1.1 Stack encoding OAM packets a

29、re differentiated from normal user-plane traffic by an increase of one in the label stack depth at a given LSP level at which they are inserted. Therefore, they maintain this label stack difference of one (from normal user-plane traffic) as they traverse any lower layer server LSPs. Label The OAM Al

30、ert Labelled header is added before (i.e., below) the normal user-plane forwarding labelled header at the LSP trail source point. EXP The OAM packets can be used on both E-LSPs and L-LSPs. The coding of the EXP field should be set to all 0s in the OAM Alert Labelled header and to whatever is the “mi

31、nimum loss-probability PHB“ in the preceding normal user-plane forwarding header for that LSP. This is to ensure the OAM packets have a PHB which ensures the lowest drop probability 5. OAM capabilities defined in the future may require different encoding of the EXP field. S bit The S bit is set only

32、 in the OAM Alert Labelled header. TTL The TTL field should be set to 1 in the OAM Alert Labelled header. The reasons for this are: OAM packets should never travel beyond the LSP trail termination sink point at the LSP level they were originally generated (noting that they are not examined by interm

33、ediate label-swapping LSRs, and are only observed at LSP sink points). the TTL of the immediately prior normal user-plane forwarding header is used to mitigate against damage from looping packets. 8 ITU-T Rec. Y.1711 (02/2004) 6.1.2 Intermediate/penultimate processing OAM packets are transparent to

34、intermediate LSRs, including the penultimate LSRs. 6.1.3 Server/client relationships OAM packets within a given LSP are not synchronous to any other OAM packets in any other LSP (this includes all nested LSPs, and OAM packets from the remote end of an LSP at level N but in the other direction when b

35、idirectional LSPs at level N are being used). 6.1.4 TTSI (Trail Termination Source Identifier) structure The structure of the LSP Trail Termination Source Identifier (TTSI) is defined by using a 16-octet LSR ID IPv6 address followed by a 4-octet LSP Tunnel ID. Note that the first 2 octets (MSB octet

36、s) of the LSP Tunnel ID are currently padded with all 0s to allow for any future increase in the Tunnel ID field. LSR ID LSP ID 16 octets 4 octets Figure 1/Y.1711 TTSI structure For nodes that do not support IPv6 addressing, an IPv4 address can be used for the LSR ID using the format described in RF

37、C 2373 7. That is: All 00Hex padding All FFHex padding IPv4 address 10 octets 2 octets 4 octets Figure 2/Y.1711 LSR ID structure using IPv4 address The TTSI provides the network-unique access point identifier of an LSP. It belongs to the traffic data-plane, and must be consistent and independent of

38、which applications use the LSP and/or how the LSP was instantiated, e.g., by management provisioning or signalling. 6.1.5 Provisioning and signalling of expected TTSI at LSP sink points On LSP establishment the LSP trail termination sink point should be configured with the expected TTSI. Although it

39、 could be configured manually, ideally this should be done automatically via LSP signalling at LSP set-up time (e.g., via a CR-LDP or RSVP control-plane mechanism). TTSI (Trail Termination Source Identifier) forms a network unique access point identifier constructed from the source LSR identifier an

40、d the LSP identifier. Mechanisms for automatic signalling/configuration of TTSI for near-end monitoring of CV and FFD are for further study. NOTE Attention is drawn to the fact that the activation/deactivation of CV/FFD/FDI/BDI functionality needs to be closely tied to the conscious set-up/tear-down

41、 of LSPs. This is necessary in order to ensure that consequent actions (especially alarms) are enabled/disabled as appropriate. For example, it is obvious that CV or FFD processing should be activated (deactivated) after (before) an LSP is set up (taken down). 6.2 Connectivity Verification (CV) The

42、Connectivity Verification function is used to detect/diagnose all types of LSP connectivity defects (sourced either from below or within the MPLS layer networks). ITU-T Rec. Y.1711 (02/2004) 9 Payload Structure Function type (01Hex) Reserved (all 00Hex) LSP Trail Termination Source Identifier Paddin

43、g (all 00Hex) BIP16 1 octet 3 octets 20 octets 18 octets 2 octets Figure 3/Y.1711 CV payload structure More information is given in Appendix I about various ingress/egress processing options. 6.3 Fast Failure Detection (FFD) The fast failure detection function is used to detect connection verificati

44、on at a smaller time-scale compared to CV functionality. In addition, like CV OAM, it detects all types of LSP connectivity defects (sourced either from below or within the MPLS layer networks). Payload Structure Function type (07Hex) Reserved (all 00Hex) LSP Trail Termination Source Identifier Freq

45、uency Padding (all 00Hex) BIP16 1 octet 3 octets 20 octets 1 octet 17 octets 2 octets Figure 4/Y.1711 FFD payload structure Where Frequency is one of: 00 reserved 01 10 ms 02 20 ms 03 50 ms (default value) 04 100 ms 05 200 ms 06 500 ms 07-255 reserved If a reserved value is received, the egress cann

46、ot determine the frequency of probe injection by the ingress; therefore dLOCV is not a valid defect state. 6.4 Forward Defect Indication (FDI) Forward Defect Indication is generated by a LSR detecting any defect (defined later) and inserted into affected client layers. FDI OAM packets are generated

47、on a nominal 1 per second basis. The FDI packet traces forward and upward through any nested LSP stack. Its primary purpose is to suppress alarms being raised at affected higher level client LSPs and (in turn) their client layers (where the higher layer clients may not be in the same management doma

48、in as the initial defect source). It includes fields to indicate the nature of the defect and its location. Near-end defect processing for MPLS LSPs or serving layer links will suppress FDI generation for MPLS client layers/levels that may have downstream merge points prior to the LSP egress. At the

49、 present time this includes LSPs set-up using LDP and LSPs set-up with RSVP-TE enhanced with FRR. 10 ITU-T Rec. Y.1711 (02/2004) The FDI is sent downstream from the first node detecting the defect. In the case of MPLS server layer failures (i.e., in a lower layer technology such as SDH), this would be the first LSR downstream of the server layer failure (as a consequence of the appropriate client/server adaptation of the server FDI signal). In the case of MPLS layer failures (i.e., failures within the MPLS fabric), this would be the first LSR LSP trai