MPLS and Ethernet OAM Interworking
draft-ietf-pwe3-mpls-eth-oam-iwk-05
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7023.
|
|
---|---|---|---|
Authors | Dinesh Mohan , Dr. Nabil N. Bitar , Philippe Niger , Ray Qiu , Simon DeLord | ||
Last updated | 2012-04-16 | ||
Replaces | draft-mohan-pwe3-mpls-eth-oam-iwk | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-06)
by David Black
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Waiting for WG Chair Go-Ahead | |
Document shepherd | Matthew Bocci | ||
IESG | IESG state | Became RFC 7023 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-pwe3-mpls-eth-oam-iwk-05
amp; Ethernet OAM Interworking April 2012 - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, and the MEP associated with the AC is configured to not support Interface Status TLV in CCM messages, the MEP associated with the AC must resume transmitting CCM frames to the peer MEP in the client domain (e.g., on CE1). - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Active. Further, if the PW receive defect was explicitly detected by PE1, it must now notify PE2 about clearing of Receive Defect state by clearing reverse defect notification. For PWs over MPLS PSN or MPLS-IP PSN, this is either done via PW Status message indicating working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08/0x20 had been negotiated. When Native Service OAM mechanism is supported on PE, it can also clear the NS OAM notification specified in Section 3.1. If PW receive defect was established via notification from PE2 or via loss of control adjacency, no additional action is needed, since PE2 is expected to be aware of the defect clearing. 5.3. PW Transmit Defect Entry Procedures When the PW status transitions from working to PW Transmit Defect state, PE1's ability to transmit user traffic to CE2 is impacted. As a result, PE1 needs to notify CE1 about this problem which has been detected by PE1. Upon entry to the PW Transmit Defect state, the following must be done: - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC MUST set the RDI bit in transmitted CCM frames or send status TLV with interface down to the peer MEP in the client domain (e.g. on CE1). Bitar, et al. Expires October 2012 [Page 14] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 - If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Not Active. 5.4. PW Transmit Defect Exit Procedures When the PW status transitions from PW Transmit Defect state to working, PE1's ability to transmit user traffic to CE2 is restored. As a result, PE1 needs to cease defect notifications to CE1 and perform the following: - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC must clear the RDI bit in the transmitted CCM frames to the peer MEP (e.g., on CE1). - If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must transmit E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that PW is Active. 5.5. AC Receive Defect Entry Procedures When AC status transitions from working to AC Receive Defect state, PE1's ability to receive user traffic from CE1 is impacted. As a result, PE1 needs to notify PE2 and CE1 about this problem. If the AC receive defect is detected by PE1, it must notify PE2 in the form of a forward defect notification. When NS OAM is not supported on PE1, and for PW over MPLS PSN or MPLS-IP PSN, forward defect notification is done via either PW Status message indicating a forward defect or via VCCV-BFD diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had been negotiated. When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 3.1. In addition to above actions, PE1 must perform the following: Bitar, et al. Expires October 2012 [Page 15] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC must set the RDI bit in transmitted CCM frames. 5.6. AC Receive Defect Exit Procedures When AC status transitions from AC Receive Defect to working, PE1's ability to receive user traffic from CE1 is restored. As a result, PE1 needs to cease defect notifications to PE2 and CE1 and perform the following: - When NS OAM is not supported on PE1 and for PW over MPLS PSN or MPLS-IP PSN, forward defect notification is cleared via PW Status message indicating a working state; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08 or 0x20 had been negotiated. - When Native Service OAM mechanism is supported on PE1, PE1 clears the NS OAM notification as specified in Section 3.1. - If PE1 is configured with a down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC must clear the RDI bit in transmitted CCM frames to the peer MEP in the client domain (e.g., on CE1). 5.7. AC Transmit Defect Entry Procedures When AC status transitions from working to AC Transmit Defect, PE1's ability to transmit user traffic to CE1 is impacted. As a result, PE1 needs to notify PE2 about this problem. If the AC transmit defect is detected by PE1, it must notify PE2 in the form of a reverse defect notification. When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS-IP PSN, reverse defect notification is either done via PW Status message indicating a reverse defect; or via VCCV-BFD diagnostic code of reverse defect if VCCV CV type of 0x08 or 0x20 had been negotiated. Bitar, et al. Expires October 2012 [Page 16] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 When Native Service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 3.1. 5.8. AC Transmit Defect Exit Procedures When AC status transitions from AC Transmit defect to working, PE1's ability to transmit user traffic to CE1 is restored. As a result, PE1 must clear reverse defect notification to PE2. When NS OAM is not supported on PE1 and for PW over MPLS PSN or MPLS-IP PSN, reverse defect notification is cleared via either a PW Status message indicating a working state or via VCCV-BFD diagnostic code if VCCV CV type of 0x08 had been negotiated. When Native Service OAM mechanism is supported on PE1, PE1 can clear NS OAM notification as specified in Section 3.1. 6. Acknowledgments The authors are thankful to Samer Salam for his valuable comments. 7. Security Considerations This document does not impose any security concerns since it makes use of existing OAM mechanisms and mapping of these messages does not change inherent security features. 8. IANA Considerations This document has no actions for IANA. 9. References 9.1. Normative References [Y.1731] "OAM Functions and mechanisms for Ethernet based networks", ITU-T Y.1731, May 2006 [802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, July 2007 Bitar, et al. Expires October 2012 [Page 17] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447, April 2006 [RFC5885] "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC5885, June 2010 [802.3] "CDMA/CD access method and physical layer specifications", Clause 57 for Operations, Administration and Maintenance, 2005 [MEF16] "Ethernet Local Management Interface", MEF16, January 2006 9.2. Informative References [RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, April 2005 [RFC6310] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf- pwe3-oam-msg-map-14.txt, Work in progress, October 2010 [RFC5659] "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", RFC5659, October 2009 10. Appendix A: Ethernet Native Service Management Ethernet OAM mechanisms are broadly classified into two categories: Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 provides coverage for both FM and PM while IEEE 802.1ag provides coverage for a sub-set of FM functions. Ethernet OAM also introduces the concept of Maintenance Entity (ME) which is used to identify the entity that needs to be managed. An ME is inherently a point-to-point association. However, in case of a multipoint association, Maintenance Entity Group (MEG) consisting of different MEs is used. IEEE 802.1 uses the concept of Maintenance Association (MA) which is used to identify both point-to-point and multipoint associations. Each MA consists of Maintenance End Points (MEPs) which are responsible for originating OAM frames. In between the MEPs, Bitar, et al. Expires October 2012 [Page 18] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 there can also be Maintenance Intermediate Points (MIPs) which do not originate OAM frames however do respond to OAM frames from MEPs. Ethernet OAM allows for hierarchical maintenance entities to allow for simultaneous end-to-end and segment monitoring. This is achieved by having a provision of up to 8 Maintenance Domain Levels (MD Levels) where each MEP or MIP is associated with a specific MD Level. It is important to note that the common set of FM mechanisms between IEEE 802.1ag and ITU-T Y.1731 are completely compatible. The common FM mechanisms include: 1) Continuity Check Messages (CCM) 2) Loopback Message (LBM) and Loopback Reply (LBR) 3) Linktrace Message (LTM) and Linktrace Reply (LTR) CCM messages are used for fault detection including misconnections and mis-configurations. Typically CCM messages are sent as multicast frames or Unicast frames and also allow RDI notifications. LBM/LBR are used to perform fault verification, while also allow for MTU verification and CIR/EIR measurements. LTM/LTR can be used for discovering the path traversed between a MEP and another target MIP/MEP in the same MA. LTM/LTR also allow for fault localization. In addition, ITU-T Y.1731 also specifies the following FM functions: 4) Alarm Indication Signal (AIS) AIS allows for fault notification to downstream and upstream nodes Further, ITU-T Y.1731 also specifies the following PM functions: 5) Loss Measurement Message (LMM) and Reply (LMR) 6) Delay Measurement Message (DMR) and Reply (DMR) 7) 1-way Delay Message (1DM) While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is used to measure single-ended (aka two-way) Frame Delay (FD) and Frame Delay Variation (FDV, also known as Jitter). 1DM can be used Bitar, et al. Expires October 2012 [Page 19] Internet-Draft MPLS & Ethernet OAM Interworking April 2012 for dual-ended (aka one-way) FD and FDV measurements. Authors' Addresses: Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON K2H8E9 Email: dinmohan@hotmail.com Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02145 Email: nabil.n.bitar@verizon.com Simon Delord Telstra 242 Exhibition St Melbourne VIC 3000, Australia E-mail: simon.a.delord@team.telstra.com Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France E-mail: philippe.niger@francetelecom.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Ray Qiu 330 Central Expressway Santa Clara, CA 95050, US Email: ray@huawei.com Bitar, et al. Expires October 2012 [Page 20]