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
