1、 INTERNATIONAL TELECOMMUNICATION UNION ITU-T Y.1710TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2002) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE AND INTERNET PROTOCOL ASPECTS Internet protocol aspects Operation, administration and maintenance Requirements for Operation users of this Recommen
2、dation 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 does not giv
3、e it, as a stand-alone document, the status of a Recommendation. 1 ITU-T Recommendation I.610 (1999), B-ISDN operation and maintenance principles and functions. 2 ITU-T Recommendation M.20 (1992), Maintenance philosophy for telecommunication networks. 3 ITU-T Recommendation G.805 (2000), Generic fun
4、ctional architecture of transport networks. 4 IETF RFC 3032 (2001), MPLS Label Stack Encoding. 5 IETF RFC 3031 (2001), Multiprotocol Label Switching Architecture. 3 Definitions This Recommendation introduces some functional architecture terminology that is required to discuss the network components
5、associated with OAM. Since functional architecture terminology may not be familiar to all readers, the relevant terms are defined below. 3.1 defect: Interruption of the capability of a transport entity (e.g. network connection) to transfer user or OAM information 2. 3.2 failure: Termination of the c
6、apability of a transport entity to transfer user or OAM information. A failure can be caused by a persisting defect 2. 4 Symbols and abbreviations This Recommendation uses the following abbreviations. ATM Asynchronous Transfer Mode DoS Denial of Service FR Frame Relay IP Internet Protocol LSN Label
7、Switching Node LSP Label Switched Path 2 ITU-T Rec. Y.1710 (11/2002) MPLS Multiprotocol Label Switched NMS Network Management System OAM Operation and Maintenance OTN Optical Transport Network SDH Synchronous Digital Hierarchy SLA Service Level Agreement 5 Introduction The motivations for this Recom
8、mendation arose from the need, expressed by network operators,for architecturally correct defect handling of MPLS Label Switched Paths (LSPs), noting that LSPs can support many different client layer networks (eg IP, FR, ATM) and can in turn be supported on many different server layer networks (eg S
9、DH/SONET, OTNs). User-plane OAM mechanisms are also required to verify that LSPs maintain correct connectivity and can deliver customer traffic against measurable availability and network performance Service Level Agreements (SLAs). NOTE Network performance metrics are not covered by this Recommenda
10、tion. The requirements presented in this Recommendation include (but are not limited to): Mechanisms to efficiently detect, identify, and localize defects arising within the MPLS layer networks. Mechanisms for defect notification and defect handling, e.g. suppress alarm storms in nested LSP scenario
11、s. Specification of the criteria for defining the availability (entry/exit) of LSPs and the relationship of availability and network performance metrics. Provide a trigger mechanism for protection switching when failures occur. 6 Motivations for MPLS OAM functions It is recognized that OAM functiona
12、lity is important in public networks for ease of network operation, for verifying network performance, and to reduce operational costs. OAM functionality is especially important for networks that are required to deliver (and hence be measurable against) network performance and availability objective
13、s. The major motivations for MPLS OAM are further discussed below. a) MPLS introduces a unique layer network capability, and hence there will be failure modes that are only relevant to MPLS layer networks. Lower-layer (server-layer) or higher-layer (client-layer) OAM mechanisms of non-MPLS technolog
14、ies cannot act as a substitute for MPLS layer OAM functionality. This observation is also critical to ensure network layer technologies can evolve independently. The MPLS nesting capability (realized through label stack encoding 5) allows the creation of multiple layer networks in their own right, w
15、ithin the framework of the MPLS technology. It should be noted that there is no fixed hierarchy in MPLS and, in theory (at least), the nesting depth can be unlimited. MPLS user-plane defects are those that are encountered during the transport of customer traffic. Although MPLS control-plane OAM func
16、tions may be available (though not always), Network Operators cannot rely exclusively on the control-plane to detect all user-plane defects. Some reasons for this are: The user-plane carrying customer traffic and the control-plane carrying the signalling protocols might not necessarily have the same
17、 routing and they will certainly not be subject to the same processing within nodes or indeed the same failure mechanisms. ITU-T Rec. Y.1710 (11/2002) 3 Therefore, the behaviour of the control-plane protocols, or the control-plane it is transported over, cannot be relied upon to indicate the health
18、of the user-plane carrying customer traffic. It is possible for an MPLS network not to have control-plane signalling at all, i.e. when LSPs are set up statically. The control-plane itself could fail but this might not have any impact on the customer traffic carrying user-plane. Further, as is requir
19、ed for the case of supporting (and being supported by) different client (and server layer) technologies, it is essential that the MPLS user-plane OAM mechanisms are independent of the control-plane protocols to allow each set of protocols to evolve independently. Indeed, in the general case, it shou
20、ld be observed that both the user-plane carrying the control-plane traffic, and the control-plane protocols themselves, need their own independent OAM mechanisms. The key requirement that should be deduced from the above discussion, is that operators want a single MPLS OAM solution that is architect
21、urally correct and control-plane independent under all network scenarios. b) Operators need an ability to determine LSP availability and network performance noting that network performance metrics are only meaningful when the LSP is in the available state. This information may also be used for accou
22、nting and billing purposes to ensure that customers are not inappropriately charged for degraded service or service outages. c) Reduce operating costs, by allowing efficient detection handling, and diagnosis of defects. Lack of automatic defect detection and handling forces operators to increase the
23、ir engineering and support workforce, hence increasing overall operating costs. d) Reduce the duration of defects and thus improve the availability performance. e) Demonstrate a commitment to providing customer traffic security/confidentiality by ensuring that any defects that result in misdirected
24、customer traffic are detectable/diagnosable and lead to appropriate actions, e.g. squelching of traffic where relevant. f) Minimize the number of defects that are not automatically detected and still require a customer to report a problem. Pro-active maintenance actions like this also help drive dow
25、n operating costs by minimizing the opportunity for incorrect defect diagnosis, and (like the previous item) they also promote customer trust of an operator. g) Allow differentiation of defects arising from lower layers from those originating from within the concerned LSP, in order to achieve more i
26、ntelligent protection-switching actions. 7 Requirements for MPLS OAM functions The following requirements should be satisfied by MPLS OAM: a) Both on-demand and continuous connectivity verification of LSPs to confirm that defects do not exist on the monitored LSPs. b) If a defect occurs, it is neces
27、sary to detect it, diagnose it, localize it, notify the NMS and take corrective actions appropriate to the type of defect. The primary objective here is to reduce operating costs by minimizing service interruptions, operational repair times and operational resource. In some cases, service interrupti
28、ons can be minimized by providing the network with sufficient information to take corrective actions to bypass the defect; for example, through protection switching or restoration. c) The OAM mechanisms provided should ensure (as far as reasonably practicable) that customers should not have to act a
29、s failure detectors. It is therefore necessary that defects be detected and notified automatically. 4 ITU-T Rec. Y.1710 (11/2002) d) At least the following defect types should be automatically detected, with well-defined entry/exit criteria and appropriate consequent actions: simple loss of LSP conn
30、ectivity, be this from below or within the MPLS fabric (it should also be possible to distinguish between these); swapped LSPs; unintended LSP replication of one LSPs traffic into another LSPs traffic (with or without the offending LSPs traffic being impacted); unintended self-replication (e.g., loo
31、ping, DoS attack). e) A defect event in a given layer network should not cause multiple alarm events to be raised, nor cause unnecessary corrective actions to be taken in any higher level client-layer networks. This applies to all client layer network types that an MPLS LSP is required to carry. The
32、re should clearly never be any impact to network layers below the level at which the defect occurs. f) OAM functions should be simple and easily configured (ideally, automatically) to allow efficient scaling to large size networks. g) The use of MPLS OAM functions should be optional for the operator
33、. Network operators should be able to choose which OAM functions to use and which LSPs they apply them to. h) MPLS OAM functions should be backward compatible. Label Switching Nodes (LSNs) that do not support such functions should silently discard the OAM packets without disturbing the user traffic
34、or causing unnecessary actions 5. i) There should be a capability to measure availability and network performance of an LSP. Since network performance metrics are only meaningful when the LSP is in the available state, then the entry/exit of the available state, and all appropriate consequent action
35、 (like the starting/stopping of network performance metric aggregation), should be specified. j) The OAM functionality of an MPLS layer network should not be dependent on any specific server or client-layer network. This is architecturally critical to ensure that layer networks can evolve (or new/ol
36、d layer networks be added/removed) without impacting other layer networks. k) The user-plane OAM functionality of an MPLS layer should be sufficiently independent on any specific control-plane such that changes in the control plane do not impose changes in user-plane OAM (including the case of no co
37、ntrol-plane). Like the previous requirement, this is also architecturally critical to ensure that user-plane and control-plane protocols can evolve (or new/old control-plane protocols added/removed) without impacting each other. l) Connectivity status assessment should not be dependent on the dynami
38、c behaviour of customer traffic. m) The OAM function should perform reliably even under degraded link conditions, e.g. error events. This requires bit error correction or detection mechanisms for OAM packets. Printed in Switzerland Geneva, 2003 SERIES OF ITU-T RECOMMENDATIONS Series A Organization o
39、f the work of ITU-T Series B Means of expression: definitions, symbols, classification Series C General telecommunication statistics Series D General tariff principles Series E Overall network operation, telephone service, service operation and human factors Series F Non-telephone telecommunication
40、services Series G Transmission systems and media, digital systems and networks Series H Audiovisual and multimedia systems Series I Integrated services digital network Series J Cable networks and transmission of television, sound programme and other multimedia signals Series K Protection against int
41、erference Series L Construction, installation and protection of cables and other elements of outside plant Series M TMN and network maintenance: international transmission systems, telephone circuits, telegraphy, facsimile and leased circuits Series N Maintenance: international sound programme and t
42、elevision transmission circuits Series O Specifications of measuring equipment Series P Telephone transmission quality, telephone installations, local line networks Series Q Switching and signalling Series R Telegraph transmission Series S Telegraph services terminal equipment Series T Terminals for
43、 telematic services Series U Telegraph switching Series V Data communication over the telephone network Series X Data networks and open system communications Series Y Global information infrastructure and Internet protocol aspects Series Z Languages and general software aspects for telecommunication systems *23051*
