MPLS Working Group Y.Koike Internet Draft NTT M.Paul Deutsche Telekom Intended status: Informational Expires: September 9, 2010 March 8, 2010 MPLS-TP OAM Maintenance Points draft-koike-ietf-mpls-tp-oam-maintenance-points-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 9, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Koike and al Expires October 11, 2010 [Page 1] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 Abstract MPLS transport profile (MPLS-TP) is designed to enable carrier grade packet transport and complement converged packet network deployments. Among the most important features of MPLS-TP are comprehensive OAM functions which enable network operators or service providers to provide various kinds of service characteristics such as prompt fault location, substantial survivability, performance monitoring and preliminary or in-service measurements. For the realization of those features by the MPLS Transport Profile, the definition of the maintenance points at which OAM messages are initiated, terminated and processed is very important. Based on the MPLS-TP OAM requirements this document elaborates on and gives guidance about maintenance points in MPLS-TP networks. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. Table of Contents 1. Introduction................................................4 2. Conventions used in this document............................4 2.1. Terminology............................................5 2.2. Definitions............................................5 3. General characteristics of maintenance operations in transport networks.......................................................5 4. Location of maintenance points...............................6 4.1. Types of MEP location...................................7 4.1.1. Per-node MEP.......................................7 4.1.2. Per-interface MEP..................................7 4.2. Types of MIP location...................................8 4.2.1. Per-node MIP.......................................8 4.2.2. Per-interface MIP..................................9 5. Dependency of OAM capability and the location of maintenance points........................................................10 5.1. Fault location........................................12 5.2. Performance Monitoring.................................14 6. Analysis of MEP&MIP location for different OAM functions.....14 6.1. Continuity Check.......................................15 6.2. Connectivity Verifications.............................15 Koike et al. Expires September 9, 2010 [Page 2] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 6.3. Route Tracing.........................................15 6.4. Diagnostic Test........................................16 6.5. Lock Instruct.........................................16 6.6. Lock Reporting........................................16 6.7. Alarm Reporting........................................16 6.8. Remote Defect Indication...............................16 6.9. Client Failure Indication..............................16 6.10. Packet Loss Measurement...............................17 6.11. Packet Delay Measurement..............................17 7. Requirements for the location of MPLS-TP OAM maintenance points18 8. Security Considerations.....................................18 9. IANA Considerations........................................18 10. References................................................18 10.1. Normative References..................................18 10.2. Informative References................................20 11. Acknowledgments...........................................20 Koike et al. Expires September 9, 2010 [Page 3] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 1. Introduction A packet transport network will enable carriers or service providers to use network resources efficiently and reduce network cost. For carrier grade network operation appropriate maintenance operations such as prompt fault location, substantial survivability, performance monitoring, preliminary and in-service measurement are essential factors to ensure quality and reliability of the network. These operational characteristics are essential features of transport networks and have evolved long with TDM evolution, ATM, SDH and OTN. Unlike in SDH or OTN networks where OAM is an inherent part of every frame and frames being also transmitted in idle mode, in packet networks it is not per se possible to constantly monitor the status of individual connections. In other words, packet transport networks rely on additional measures, i.e. OAM functions and proper location of maintenance points. On the other hand, packet based OAM functions are flexible and selectively configurable to operator's needs. According to the MPLS-TP OAM requirements [6] mechanisms MUST be available for a service provider to be aware of a fault or defect affecting the service(s) he provides. To ensure that faults can be localized and connections can be traced through network elements, links, intra-domain and inter-domain interfaces, it is important to define the appropriate location of OAM maintenance points which are responsible for processing OAM messages and performing OAM functions. If maintenance points are not defined properly, any excellent OAM function for pro-active and on-demand maintenance may become meaningless or less effective. In addition, it is also important to clarify how those OAM maintenance points are utilized by each maintenance mechanism, in other words, each OAM function. If OAM processing at each OAM maintenance point is not clarified, network management view and operability of network elements might be unsufficient. This document clarifies requirements on OAM maintenance points by elaborating on the technical background and on deployment cases. Moreover requirements for every OAM function are also clarified based on the newly introduced deployment of maintenance points. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Koike et al. Expires September 9, 2010 [Page 4] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 2.1. Terminology CE Customer Edge FW Forwarding Engine I/F Interface LSP Label Switched Path ME Maintenance Entity MEG Maintenance Entity Group MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point NE Network Element NNI Network-to-Network Interface OTN Optical Transport Network PE MPLS-TP Provider Edge LSR P MPLS-TP Provider LSR SDH Synchronous Digital Hierarchy UNI User-to-Network Interface 2.2. Definitions Most of the definitons in this draft follow those definitions in [7]. 3. General characteristics of maintenance operations in transport networks The following two characteristics (C1-C2) are significant in transport networks. C1) When a fault occurs with client traffic, it must be possible to locate the cause of the fault or defect in client data traffic, that Koike et al. Expires September 9, 2010 [Page 5] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 is, whether it is within one administrative domain or outside the domain. If a fault occurs in client traffic, it is necessary to identify whether the cause is within the responsible operator's administrative domain or outside of it. Immediate fault identification and location is an important factor for providing effective maintenance actions and avoiding high efforts for manual interventions. Therefore, C1 is an inevitable characteristic of the transport profile. C2) When a fault or a defect occurs in a connection within one administrative domain, it must be possible to locate whether the cause is within a node or between two neighboring nodes. If the fault is within one administrative domain, the next action is to determine if the problem is located within one node or transmission line, i.e. to determine whether it is an equipment alarm or communication alarm. The basic reason the two alarms are separately defined in a transport network is dependent on the characteristic difference of the two network components, the node or the transmission line. The performance and quality of the network node is mainly determined by the switching or forwarding component, whose implementation can differ among system vendors. The performance and quality of the transmission line is mainly determined by the line card/IF component and physical transmission media. The line card/IF package is more generalized and less vendor specific as forwarding and switching components. Accordingly, the separation between the switching and transmission section is quite reasonable from the perspective of architectural design. When a fault is detected, it MUST be possible to locate the affected component or narrow the causes of the fault. This enables prompt and well-directed actions, by e.g. a replacment of packages/line cards/modules or by changing settings of the package, port, section, or connection unit. Efficiently handling this problem and avoiding any effect on other client traffic, which does not encounter faults and is not related to the fault, are important. 4. Location of maintenance points OAM maintenance points need to be specified clearly in order to meet the MPLS-TP OAM requirements [6] and the characteristics described in section 3 of this draft. OAM maintenance points include MEP and MIP. Koike et al. Expires September 9, 2010 [Page 6] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 4.1. Types of MEP location Note: Following sections will be copied to section 3.2 MEG End Points (MEPs) of OAM framework[7]. An end node within a point-to-point MEG will support per-node MEP or per-interface MEP. 4.1.1. Per-node MEP Per-node MEP is a MEP which is located somewhere within one NE. There is no other MIP on the same LSP/PW within the same NE. Source/Destination node ----------------- | | | ----- | | | | | ->-| | MEP | |->- | | | | | ----- | | | ----------------- Figure.1: Per-node MEP In this case, the location of MEP within NE is unspecified. In other words, MEP is located at ingress interface(I/F), forwarding engine(FW), egress I/F, or other parts, if any. Note: It is said that most common implementation of MEP in LSP/PW is located at ingress interface and the second common one is located at FW. However, per-node MEP doesn't restrict its location within one NE. 4.1.2. Per-interface MEP Per-interface MEP is a MEP which is located on the interface facing the client network (UNI) and being specified independently from forwarding engine. In the most cases, a per-interface MEP will be combined with a per- interface MIP which is located on the interface facing the provider network (NNI) on the same LSP/PW within the same NE. Koike et al. Expires September 9, 2010 [Page 7] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 Source/Destination node Source/Destination node ------------------------ ------------------------ | | | | |----- -----| |----- -----| | MEP | | | | | | MEP | | | ---- | | | | ---- | | ->-| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |->- | i/f | ---- | i/f | | i/f | ---- | i/f | |----- -----| |----- -----| | | | | ------------------------ ------------------------ (1) (2) Figure.2: Per-interface MEP: (1)Ingress per-interface MEP and (2) egress per-interface MEP in source/destination node Figure 2 shows two examples of per-interface MEP at source/destination node of LSP/PW. In left hand case (1) in fig.2, the destination/source MEP is located at the ingress interface before the FW in the source node and in right hand case (2) in fig.2, the source/destination MEP is located at the egress interface after the FW in destination/source node. 4.2. Types of MIP location Note: Following sections will be copied to section 3.3 MEG Intermediate Points (MIPs) of the MPLS-TP OAM framework[7]. An end or intermediate node within a point-to-point MEG will support per-node MIP or per-interface MIP. 4.2.1. Per-node MIP Per-node MIP is a MIP which is located somewhere within one NE. There is no other MIP on the same LSP/PW within the same NE. Intermediate node ----------------- | | | ----- | | | | | ->-| | MIP | |->- | | | | | ----- | | | ----------------- Koike et al. Expires September 9, 2010 [Page 8] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 Figure.3: Per-node MIP Fig.3 shows the per-node MIP model. In this model, the location of MIP within a node is unspecified. In other words, MIP is located at ingress interface (I/F), forwarding engine (FW), egress I/F or other part if any. Note: In the most cases, per-node MIPs for LSP/PW are located at ingress interface or at the FW. However, the location of per-node MIPs within one NE isn't constrained to that. 4.2.2. Per-interface MIP Per-interface MIP is a MIP which is located on a node interface, independently from the forwarding engine. In the most cases, per-interface MIP will be combined with another per-interface MIP which is located on the egress interface of the same LSP/PW within the same NE. Intermediate node ------------------------ | | |----- -----| | MIP | | MIP | | | ---- | | ->-| In |->-| FW |->-| Out |->- | i/f | ---- | i/f | |----- -----| | | ------------------------ Figure.4: Per-interface MIP: ingress MIP and egress MIP Figure 4 shows per-interface MIP model. This model has one MIP placed at the ingress interface and one MIP placed at the egress interface at a source/intermediate/destination node of LSP/PW. An ingress MIP is located at the ingress interface before the FW in an intermediate/destination node and an egress MIP is located at the egress interface after the FW in a source/intermediate node. Koike et al. Expires September 9, 2010 [Page 9] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 5. Dependency of OAM capability and the location of maintenance points In this section, the difference of OAM functional capabilities between type1 and type2 of locations of maintenance points are described. One of the most important features for maintenance operation is to appropriately set and use points at which fault location, performance monitoring or diagnostic test is done. As described in section 4, there are mainly two different assignments of maintenance points, that is, type1 and type2. In case of type 1 MIP or MEP, only one maintenance point exists somewhere within a node. In case of type2 MIP or MEP, two maintenance points exist per node, i.e. one at the ingress interface and one at the egress interface. Following section shows the comparison of OAM maintenance capabilities between type1 and type2. For type 1, the location of a maintenance point (MIP or MEP) is not specified within one NE. Type1 is basically classified into two options (located at ingress interface or at the forwarding engine), when currently deployed implementations are considered. The most common location of maintenance point of LSP/PW is at ingress interface. Therefore the location of maintenance point is assumed at ingress interface in the following comparisons. Customer| Operator's administrative | Customer Domain | Domain | Domain ------> |<------------------------------------ ->| <------ CE1 | PE1 P1 PE2 | CE2 | <--------> <--------> <--------> | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | In FW Out In FW Out In FW Out | | | FWD LSP | o---------------------------> | | V-------------*-------------V | | MEP1 MIP1 MEP2 | BWD LSP | <---------------------------o | | V-------------*-------------V | | MEP1' MIP1' MEP2'| (S1)<============> (S2)<==========================> Figure.5: Example of per-node MIP and MEP Koike et al. Expires September 9, 2010 [Page 10] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 Customer Operator's administrative Customer Domain Domain Domain ------->|<--------------------------------------->|<------ CE1 | PE1 P1 PE2 | CE2 | <--------> <--------> <--------> | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | In FW Out In FW Out In FW Out | | | FWD LSP | o-----------------------------------> | | V-------*------*------*-----*-------V | | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| | | BWD LSP | <-----------------------------------o | | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| (S'1)<======> (S'2)<=============> (S'3)<====================> (S'4)<==========================> (S'5)<==================================> Figure.6: Example of per-interface MIP and MEP Koike et al. Expires September 9, 2010 [Page 11] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 Fig.5 shows the per-node model of maintenance points when some connection service is provided between CE1 and CE2. A LSP is established between PE1 and PE2. MEP1 in forward direction and MEP1' in backward direction are located within a same PE1. In the same manner, a pair of MIP1 and MIP1' and a pair of MPE2 and MEP2' are located within a same P1 and PE2 respectively. In fig.5, MIP and MEP at each label edge router (LER) is located at different position within the router in forward direction and backward direction respectively for comparison between per-node MIP&MEP(fig.5) and per-interface MIP&MEP(fig.6). Strictly speaking, in forward direction MEP1 is set at ingress interface of PE1 and MEP2 is set at ingress interface of PE2. MIP1 is set at ingress interface P1. Moreover, MIP1', MEP1' and MEP2' in unidirectional LSP of backward direction from egress interface of PE2 to egress interface of PE1 is also described. Figure 6 shows the per-interface model of maintenance points when some connection service is provided between CE1 and CE2. A LSP is set between PE1 and PE2. In forward direction, MEP1 is set at ingress interface(In) of PE1 and MEP2 is set at egress interface(Out) of PE2. MIP1 is set at egress interface of PE1, MIP2 is at in-I/F of P2, MIP3 is at out-I/F of P3, MIP4 is at in-I/F of PE2. Moreover, LSP of backward direction from out-I/F of PE2 to in-I/F of PE1 is also described. In this case, MIPs and MEPs at each label edge router are located at the same position within the router in forward direction and backward direction respectively. 5.1. Fault location The following two cases based on Fig.5 and Fig.6 compare the different characteristic between per-node MIP&MEP and per-interface MIP&MEP in terms of fault location. Locations of maintenance points in per-node MIP&MEP in fig.5 can cause two concrete problems, relating to characteristics (C1) and (C2) in section 3. The following 2 cases are considered, where on-demand CV is exemplified as mechanism for fault location: Case 1: Customer traffic between CE1 and CE2 contains a fault and on- demand CV from PE1 to PE2 is OK Case 2: On-demand CV from PE1 to P fails (NG). Koike et al. Expires September 9, 2010 [Page 12] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 Case 1 highlights a scenario where the fault is located in the client domain or operator domain. The suspected fault points are forwarding engine(FW) in PE2, out-going interface(Out) in PE2, transmission line between PE2 and CE2 or CE2. In case of the per-node model in fig.5, on-demand CV can only be performed on segment2(S2). With only one maintenance point per node, it is impossible to precisely identify the fault location. In case of per-interface model in fig.6, there are five segments where on-demand CV can be performed. Although S2 in fig.5 corresponds to S4' in fig.6, on-demand CV can also be conducted in S'5 in case of per-interface model in fig.6. Adding MEP2 in PE2 enables to obtain additional information and more precisely locate the fault by using on-demand CV. If the result of on-demand CV in S4' is OK, the fault location range can be limited to the transmission line between ME2 and CE2 or out- going IF(Out) in PE2. If the result of on-demand CV in S4' is NG, the fault is at egress IF(Out) in PE2 or at the forwarding engine in PE2. In packet network, miss-configuration might be the cause of connection fault more often than hardware failure of packages. As a result, per-interface model provide more effective fault location function than per-node model. Per-interface model makes it easy to locate the cause of the fault or defect in client data traffic, that is, whether it is within one administrative domain or outside the domain. Note: Interaction with client OAM / attachment circuit has to be done on another OAM level, i.e. by link OAM or an end-to-end service OAM on the client service layer and by OAM message mapping. This is for further study. Case 2 highlights a scenario where the fault is located on the interface or transmission line within operator's domain. In case of the per-node model in fig.5, segment1 (S1) is the only pattern where on-demand CV can be performed. With only one maintenance point per node, it is impossible to precisely identify the fault location. On the other hand, in case of per-interface model in fig.6, there are five segments in total where on-demand CV can be performed. Although S1 in fig.5 corresponds to S2' in fig.6, on- demand CV can also be conducted in S'1 in case of per-interface model in fig.6. Adding MIP2 in PE1 enables to obtain additional information and more precisely locate the fault by using on-demand CV. Koike et al. Expires September 9, 2010 [Page 13] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 As explained above, setting maintenance points on both sides of the switch fabric in per-interface model enables operators to locate faults more precisely and as a result, perform maintenance more efficiently than in per-node model. Operators have to indentify the location of MEP particularly in per-node model. This comparison of maintenance capability is applied to not only on- demand CV which is exemplified in this section but also other OAM functions such as a proactive continuity check, proactive on-demand connectivity verification, on-demand route tracing, on-demand loss measurement, on-demand delay measurement and diagnostic test. 5.2. Performance Monitoring According to MPLS-TP OAM requirements, performance monitoring has to be supported by loss measurement and delay measurement function. Those are supported between two MEPs. In case of per-node MEP model as per fig.5, the segment where the performance of LSP/PW is monitored is S2 between MEP1 and MEP2 in the forward direction. Therefore, if some degrade happened between In and Out in PE2, it is impossible to detect the degradation on this segment. In case of per-interface MEP model as per fig.6, the measurable segment is S'5 between MEP1 and MEP2 in the forward direction and whole connection is covered end-to-end. There is no segment which is not measurable. It is highly propable that the LER can become a cause for degradation of services. In that case, the difference between per-node model and per-interface model could be critical. Operators have to be careful about the location of MEP in per-node model. 6. Analysis of MEP&MIP location for different OAM functions Note: Following sections will be copied to section 5 OAM Functions for proactive monitoring and to 6. OAM Functions for on-demand monitoring of the MPLS-TP OAM framework[7]. The most appropriate destination will be the passages which describe defects for each OAM function. Koike et al. Expires September 9, 2010 [Page 14] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 6.1. Continuity Check There is a difference of defect detection capability between per- interface and per-node model. In case of per-node model, maintenance points are not specified with in NE, therefore, there is a possibility that some defects are not detected depending on the location of the defect. In case of per-interface model, there is no missing segment where defects can not be detected, compared with per- node model. In addition, in case of per-interface model, it is possible to differentiate whether the cause of the defect(s) is(are) within one administrative domain or outside the domain. It is also possible to differentiate whether the cause is within a node or between two neighboring nodes. 6.2. Connectivity Verifications There is a difference of defect detection capability between per- interface and per-node model. In case of per-node model, maintenance points are not specified with in NE, therefore, there is a possibility that some defects are not detected depending on the location of the defect. In case of per-interface model, there is no missing segment where defects can not be detected. In addition, in case of per-interface model, it is possible to differentiate whether the cause of the defect(s) is(are) within one administrative domain or outside the domain. It is also possible to differentiate whether the cause is within a node or between two neighboring nodes. 6.3. Route Tracing There is a difference of route tracing capability between per- interface and per-node model. In case of per-node model, maintenance points are not specified with in NE, therefore, there is a possibility that some segments of the route of client traffic within operator domain cannot be traced. In case of per-interface model, there is no missing segment - the route can be traced completely. In addition, in case of per-interface model, it is possible to differentiate whether the point of the failure of the route tracing is(are) within one administrative domain or outside the domain. It is also possible to differentiate whether the point is within a node or between two neighboring nodes. Koike et al. Expires September 9, 2010 [Page 15] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 6.4. Diagnostic Test There is a difference of diagnostic capability between per-interface and per-node model. In case of per-node model, maintenance points are not specified with in NE, therefore, there is a possibility that some segments of the route of the client traffic within operator domain cannot be tested. In case of per-interface model, there is no missing segment where the diagnostic test can not be conducted. In addition, in case of per-interface model, it is possible to differentiate whether the cause of the defect(s) is(are) within one administrative domain or outside the domain. It is also possible to differentiate whether the cause is within a node or between two neighboring nodes. 6.5. Lock Instruct To be incorporated in a future revision of this document, when this feature is specified in OAM framework[7]. 6.6. Lock Reporting No difference between per-interface and per-node model. Function is independent of the location of maintenance points within one node. 6.7. Alarm Reporting No difference between per-interface and per-node model. Function is independent of the location of maintenance points within one node. 6.8. Remote Defect Indication No difference between per-interface and per-node model. Function is independent of the location of maintenance points within one node. 6.9. Client Failure Indication No difference between per-interface and per-node model. CFI is associated with client failure and sent from MEP to MEP as a result of detection of client signal fail. Therefore, there is no direct impact on its capability. Koike et al. Expires September 9, 2010 [Page 16] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 6.10. Packet Loss Measurement There is a difference of packet loss measurement capability between per-interface and per-node model. In case of per-node model, the location of maintenance points is not specified within NE, therefore there is a possibility that some segments of the route of the client traffic within operator domain are not measurable. In case of per- interface model, there is no missing segment where the packet loss measurement can not be conducted. In addition, in case of per-interface model, it is possible to differentiate whether the cause of the defect(s) is(are) within one administrative domain or outside the domain. It is also possible to differentiate whether the cause is within a node or between two neighboring nodes. 6.11. Packet Delay Measurement There is a difference of packet delay measurement capability between per-interface and per-node model. In case of per-node model, the location of maintenance points is not specified within NE, therefore, there is a possibility that some segments of the route of the client traffic within operator domain are not measurable. In case of per- interface model, there is no missing segment where the packet delay measurement can not be conducted. In addition, in case of per-interface model, it is possible to differentiate whether the cause of the defect(s) is(are) within one administrative domain or outside the domain. It is also possible to differentiate whether the cause is within a node or between two neighboring nodes. Koike et al. Expires September 9, 2010 [Page 17] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 7. Requirements for the location of MPLS-TP OAM maintenance points According to the MPLS-TP OAM requirements [6] mechanisms MUST be available for a service provider to be aware of a fault or defect affecting the service(s) he provides, even if the fault or defect is located outside of his domain. It is further defined that OAM information MUST include identifiers related to the nodes and interfaces composing that route. MPLS-TP OAM maintenance points need to be specified properly in order to meet the requirements and characteristics of transport networks, as highlighted by this draft. Thus, the following detailed requirements are to be considered in the MPLS-TP OAM framework and for the MPLS-TP OAM solutions: 1) Per-node and per-interface deployment models MUST be supported. 2) At intermediate nodes, for each PW or LSP it MUST be possible to set two MIPs; one MIP on the ingress interface and another MIP on the egress interface. 3) At edge nodes, for each PW or LSP it MUST be possible to set one MIP and one MEP; one MIP on the interface facing the provider network(NNI) and one MEP on the interface facing the client network (UNI). 4) MEPs have to be set at the time when the PW or LSP is provisioned. MIPs have to be set at any time, when it is necessary or required. 8. Security Considerations This document does not by itself raise any particular security considerations. 9. IANA Considerations There are no IANA actions required by this draft. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Koike et al. Expires September 9, 2010 [Page 18] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 [2] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 [3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 [4] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 [5] Bocci, M., et al., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-10 (work in progress), February 2010 [6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 05 (work in progress), February 2010 [7] Busi, I., Niven-Jenkins, B. , "MPLS-TP OAM Framework", draft- ietf-mpls-tp-oam-framework-04.txt, December 2009 [8] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., "MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-07 (work in progress), October 2009 [9] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node interface for the synchronous digital hierarchy (SDH)", January 2007 [10] ITU-T Recommendation G.709/Y.1331 (03/03), "Interfaces for the Optical Transport Network (OTN)", March 2003 [11] ITU-T Recommendation G.805 (03/00), "Generic functional architecture of transport networks", March 2000 [12] ITU-T Recommendation G.806 (01/09), "Characteristics of transport equipment - Description methodology and generic functionality", January 2009 [13] ITU-T Recommendation G.7710 (07/07), "Common equipment management function requirements", July 2007Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Koike et al. Expires September 9, 2010 [Page 19] Internet-Draft MPLS-TP OAM Maintenance Points March 2010 10.2. Informative References 11. Acknowledgments The authors would like to thank all members (including MPLS-TP steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Yoshinori Koike (Editor) NTT Email: koike.yoshinori@lab.ntt.co.jp Manuel Paul (Editor) Deutsche Telekom Email : Manuel.Paul@telekom.de Koike et al. Expires September 9, 2010 [Page 20]