Network Working Group N.
Sprecher, Ed.Sprecher Internet-Draft Nokia Siemens Networks Intended status: Informational H. van Helvoort, Ed. Expires: September 5, 2010 HuaweiE. Bellagamba Expires: January 5, 2011 Ericsson Y. Weingarten Nokia Siemens Networks MarchJuly 4, 2010 MPLS-TP OAM Analysis draft-ietf-mpls-tp-oam-analysis-01.txtdraft-ietf-mpls-tp-oam-analysis-02.txt Abstract This document analyzes the set of requirements for Operations, Administration, and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether existing OAM tools (either from the current MPLS toolset or from the ITU-T documents) can be applied to these requirements. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to supportmap the set of OAM requirements for MPLS-TP. This document reports the conclusionsfunctions to a set of tools based on the MPLS-TP design team discussions concerning the MPLS-TPexisting OAM tools at IETF75.toolset. Status of this Memo This Internet-Draft is submitted to IETFin 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.(IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts.Drafts is at http://datatracker.ietf.org/drafts/current/. 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 SeptemberJanuary 5, 2010.2011. Copyright Notice Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Organization of the document . . . . . . . . . . . . . . . 4 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 1.4. LSP PingAcronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. MPLS BFD . . .2. Basic OAM infrastructure functionality . . . . . . . . . . . . 5 3. MPLS-TP OAM Functions . . . . . . . . . . 6 1.6. PW VCCV. . . . . . . . . . 6 3.1. Continuity Check and Connectivity Verification . . . . . . 7 3.1.1. Documents for CC-V tools . . . . . . . . . 7 1.7. IETF Performance Measurement. . . . . . 7 3.2. Remote Defect Indication . . . . . . . . . 8 1.8. ITU Recommendation Y.1731. . . . . . . . 7 3.2.1. Documents for RDI . . . . . . . . 9 1.9. Acronyms. . . . . . . . . . 7 3.3. Route Tracing . . . . . . . . . . . . . . . 11 2. Architectural requirements and general principles of operation. . . . . . . 7 3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 8 3.4. Alarm Reporting . . . . . . 11 2.1. Architectural and Principles of Operation - Recommendations and Guidelines. . . . . . . . . . . . . . 13 3. MPLS-TP OAM Functions. 8 3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 8 3.5. Lock Reporting . . . . . . . 15 3.1. Continuity Check and Connectivity Verification. . . . . . 15 3.1.1. Existing tools. . . . . . . . . 8 3.5.1. Documents for Lock Reporting . . . . . . . . . . . 15 3.1.2. Gap analysis. . 8 3.6. Diagnostic . . . . . . . . . . . . . . . . . . . 16 3.1.3. Recommendations and Guidelines. . . . . 8 3.6.1. Documents for Diagnostic Testing . . . . . . . 17 3.2. Alarm Reporting. . . . 9 3.7. Lock Instruct . . . . . . . . . . . . . . . . . 17 3.2.1. Existing tools. . . . . 9 3.7.1. Documents for Lock Instruct . . . . . . . . . . . . . 9 3.8. Client Failure Indication . . 17 3.2.2. Recommendations and Guidelines. . . . . . . . . . . . 17 3.3. Diagnostic. . 9 3.8.1. Documents for CFI . . . . . . . . . . . . . . . . . . 9 3.9. Packet Loss Measurement . . . . 17 3.3.1. Existing tools. . . . . . . . . . . . . 9 3.9.1. Documents for Packet Loss Measurement . . . . . . . 17 3.3.2. Recommendations and Guidelines. 10 3.10. Packet Delay Measurement . . . . . . . . . . . 18 3.4. Route Tracing. . . . . . 10 3.10.1. Documents for Delay Measurement . . . . . . . . . . . 10 4. IANA Considerations . . . . . 18 3.4.1. Existing tools. . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . 18 3.4.2. Recommendations and Guidelines. . . . . . . . . . . . 18 3.5. Loopback tool. . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . 18 3.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 18 3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 19 3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 19 3.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 19 3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 19 3.7.2. Recommendations and Guidelines .. . . . 11 7. Informative References . . . . . . . 19 3.8. Remote Defect Indication. . . . . . . . . . . . . 11 Authors' Addresses . . . . 19 3.8.1. Existing tools. . . . . . . . . . . . . . . . . . . . 19 3.8.2. Recommendations12 1. Introduction 1.1. Scope OAM (Operations, Administration, and Guidelines . . . . . . . . . . . . 20 3.9. Client Failure Indication . . . . . . . . . . . . . . . . 20 3.9.1. Existing tools . . . . . . . . . . . . . . . . . . . . 20 3.9.2. RecommendationsMaintenance) plays a significant role in carrier networks, providing methods for fault management and Guidelines . . . . . . . . . . . . 20 3.10. Packet Loss Measurement . . . . . . . . . . . . . . . . . 20 3.10.1. Existing tools . . . . . . . . . . . . . . . . . . . . 21 3.10.2. Recommendationsperformance monitoring in both the transport and Guidelines . . . . . . . . . . . . 21 3.11. Packet Delay Measurement . . . . . . . . . . . . . . . . . 21 3.11.1. Existing tools . . . . . . . . . . . . . . . . . . . . 22 3.11.2. Recommendations and Guidelines . . . . . . . . . . . . 22 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 22 5. MPLS-TP OAM Documents Organization . . . . . . . . . . . . . . 24 5.1. Document 1: "Encapsulation of BFD and LspPing in ACH" . . 24 5.2. Document 2: "Extended BFD" . . . . . . . . . . . . . . . . 25 5.3. Document 3: "Extended LSP Ping" . . . . . . . . . . . . . 25 5.4. Document 4: "Extensions for Lock Instruct" . . . . . . . . 26 5.5. Document 5: "AIS and Lock Reporting" . . . . . . . . . . . 26 5.6. Document 6: "Client Fault Indication" . . . . . . . . . . 26 5.7. Document 7: "Packet Loss" . . . . . . . . . . . . . . . . 27 5.8. Document 8: "Packet Delay" . . . . . . . . . . . . . . . . 27 5.9. Document 9: "Diagnostic Tests" . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Proactive CC and CV BFD tool analysis . . . . . . 27 Appendix A.1. Possible Solution . . . . . . . . . . . . . . . . 28 Appendix A.2. Backward compatibility . . . . . . . . . . . . . . 29 Appendix A.3. Definition of BFDv2 . . . . . . . . . . . . . . . 29 Appendix A.3.1. New semantic for Discriminator fields . . . . . . 29 Appendix A.3.2. New MEP ID field . . . . . . . . . . . . . . . . . 30 Appendix A.4. Two different ACH encapsulation of OAM tool . . . 30 Appendix A.4.1. New tool based on current BFD . . . . . . . . . . 31 Appendix A.4.2. New tool based on the extended BFD . . . . . . . . 31 Appendix A.4.3. New tool like Y.1731 CCM . . . . . . . . . . . . . 31 Appendix A.5. Remote Defect Indication . . . . . . . . . . . . . 31 Appendix A.6. Point to Multipoint transport paths . . . . . . . 32 Appendix A.7. Security Considerations . . . . . . . . . . . . . 32 9. Informative References . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction 1.1. Scope OAM (Operations, Administration, and Maintenance) plays a significant role in carrier networks, providing methods for fault management and performance monitoring in both the transport and the service layers in order to improve their ability to support services with guaranteed and strict Service Level Agreements (SLAs) while reducing their operational costs. [MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular define a set of requirements for OAM functionality in MPLS-Transport Profile (MPLS-TP) for MPLS-TP Label Switched Paths (LSPs) (network infrastructure) and Pseudowires (PWs) (services). The purpose of this document is to analyze the OAM requirements and evaluate whether existing OAM tools defined for MPLS can be used to meet the requirements, identify which tools need to be extended to comply with the requirements, and which new tools need to be defined. We also take the ITU-T OAM toolset, as defined in [Y.1731], as a candidate to base these new tools upon. The existing tools that are evaluated include LSP Ping (defined in [LSP Ping]), MPLS Bi- directional Forwarding Detection (BFD) (defined in [BASE BFD]) and Virtual Circuit Connectivity Verification (VCCV) (defined in [PW VCCV] and [VCCV BFD]), and the ITU-T OAM toolset defined in [Y.1731]. This document reports the conclusions of the MPLS-TP design team discussions on the MPLS-TP OAM tools at IETF75 and the guidelines that were agreed. The guidelines refer to a set of existing OAM tools that need to be enhanced to fully support the MPLS-TP OAM requirements and identify new tools that need to be defined. The organizational structure of the documents on MPLS-TP OAM tools was also discussed and agreed at IETF75 and is described later in this document. 1.2. Organization of the document Sections 1.4 - 1.8 provide an overview of the existing MPLS tools. Section 2 of the document analyzes the requirements that are documented in [MPLS-TP OAM Reqs] and provides basic principles of operation for the OAM functionality that is required. Section 3 evaluates which existing tools can provide coverage for the different OAM functions that are required to support MPLS-TP. The recommendations are summarized in section 4, and reflect the guidelines which were agreed by the MPLS-TP design team during the meetings at IETF 75. These guidelines relate to the functionality could be covered by the existing toolset and what extensions or new tools would be needed in order to provide full coverage of the OAM functionality for MPLS-TP. The OAM tools for MPLS-TP OAM will be defined in a set of documents. Section 5 describes the organization of this set of documents as agreed by the MPLS-TP design team at IETF75. 1.3. Contributing Authors Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi (Alcatel Lucent) 1.4. LSP Ping LSP Ping is a variation of ICMP Ping and traceroute [ICMP] adapted to the needs of MPLS LSP. Forwarding, of the LSP Ping packets, is based upon the LSP Label and label stack, in order to guarantee that the echo messages are switched in-band (i.e. over the same data route) of the LSP. However, it should be noted that the messages are transmitted using IP/UDP encapsulation and IP addresses in the 127/8 (loopback) range. The use of the loopback range guarantees that the LSP Ping messages will be terminated, by a loss of connectivity or inability to continue on the path, without being transmitted beyond the LSP. For a bi-directional LSP (either associated or co-routed) the return message of the LSP Ping could be sent on the return LSP. For unidirectional LSPs and in some case for bi-directional LSPs, the return message may be sent using IP forwarding to the IP address of the LSP ingress node. LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity and continuity check) with functionality to verify data- plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC) and also Maximum Transmission Unit (MTU) problems. The traceroute functionality may be used to isolate and localize the MPLS faults, using the Time-to-live (TTL) indicator to incrementally identify the sub-path of the LSP that is successfully traversed before the faulty link or node. As mentioned above, LSP Ping requires the presence of the MPLS control plane when verifying the consistency of the data-plane against the control-plane. However, LSP Ping is not dependent on the MPLS control-plane for its operation, i.e. even though the propagation of the LSP label may be performed over the control-plane via the Label Distribution Protocol (LDP). It should be noted that LSP Ping does support unique identification of the LSP within an addressing domain. The identification is checked using the full FEC identification. LSP Ping is easily extensible to include additional information needed to support new functionality, by use of Type-Length-Value (TLV) constructs. LSP Ping can be activated both in on-demand and pro-active (asynchronous) modes, as defined in [MPLS-TP OAM Reqs]. [P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. [MPLS LSP Ping] extends LSP Ping to operate over MPLS tunnels or for a stitched LSP. As pointed out above, TTL exhaust is the method used to terminate flows at intermediate LSRs. This is used as part of the traceroute of a path and to locate a problem that was discovered previously. Some of the drawbacks identified with LSP Ping include - LSP Ping is considered to be computational intensive as pointed out in [MPLS BFD]. The applicability for a pro-active mode of operation is analyzed in the sections below. Use of the loopback address range (to protect against leakage outside the LSP) assumes that all of the intermediate nodes support some IP functionality. Note that ECMP is not supported in MPLS-TP, therefore its implication on OAM capabilities is not analyzed in this document. 1.5. MPLS BFD BFD (Bidirectional Forwarding Detection) [BASE BFD] is a mechanism that is defined for fast fault detection for point-to-point connections. BFD defines a simple packet that may be transmitted over any protocol, dependent on the application that is employing the mechanism. BFD is dependent upon creation of a session that is agreed upon by both ends of the link (which may be a single link, LSP, etc.) that is being checked. The session is assigned a separate identifier by each end of the path being monitored. This session identifier is by nature only unique within the context of node that assigned it. As part of the session creation, the end-points negotiate an agreed transmission rate for the BFD packets. BFD supports an echo function to check the continuity, and verify the reachability of the desired destination. BFD does not support neither a discovery mechanism nor a traceroute capability for fault localization, these must be provided by use of other mechanisms. The BFD packets support authentication between the routers being checked. BFD can be used in pro-active (asynchronous) and on-demand modes, as defined in [MPLS-TP OAM Reqs], of operation. [MPLS BFD] defines the use of BFD for P2P LSP end-points and is used to verify data-plane continuity. It uses a simple hello protocol which can be easily implemented in hardware. The end-points of the LSP exchange hello packets at negotiated regular intervals and an end-point is declared down when expected hello packets do not show up. Failures in each direction can be monitored independently using the same BFD session. The use of the BFD echo function and on-demand activation are outside the scope of the MPLS BFD specification. The BFD session mechanism requires an additional (external) mechanism to bootstrap and bind the session to a particular LSP or FEC. LSP Ping is designated by [MPLS BFD] as the bootstrap mechanism for the BFD session in an MPLS environment. The implication is that the session establishment BFD messages for MPLS are transmitted using a IP/UDP encapsulation. In order to be able to identify certain extreme cases of mis- connectivity, it is necessary that each managed connection have its own unique identifiers. BFD uses Discriminator values to identify the connection being verified, at both ends of the path. These discriminator values are set by each end-node to be unique only in the context of that node. This limited scope of uniqueness would not identify a misconnection of crossing paths that could assign the same discriminators to the different sessions. 1.6. PW VCCV [PW VCCV] provides end-to-end fault detection and diagnostics for PWs (regardless of the underlying tunneling technology). The VCCV switching function provides a control channel associated with each PW (based on the PW Associated Channel Header (ACH) which is defined in [PW ACH]), and allows sending OAM packets in-band with PW data (using CC Type 1: In-band VCCV) VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being sent over the PW ACH. BFD for VCCV supports two modes of encapsulation - either IP/UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no IP/UDP header) and provides support to signal the AC status. The use of the VCCV control channel provides the context, based on the MPLS-PW label, required to bind and bootstrap the BFD session to a particular pseudo wire (FEC), eliminating the need to exchange Discriminator values. VCCV consists of two components: (1) signaled component to communicate VCCV capabilities as part of VC label, and (2) switching component to cause the PW payload to be treated as a control packet. VCCV is not directly dependent upon the presence of a control plane. The VCCV capability negotiation may be performed as part of the PW signaling when LDP is used. In case of manual configuration of the PW, it is the responsibility of the operator to set consistent options at both ends. 1.7. IETF Performance Measurement OWAMP (One-Way Active Measurement Protocol) [RFC4656] enables measurement of unidirectional characteristics of IP networks, such as packet loss and one-way delay. For its proper operation OWAMP requires accurate time of day setting at its end points. TWAMP (Two-Way Active Measurement Protocol) [RFC5357] is a similar protocol that enables measurement of two-way (round trip) characteristics. TWAMP does not require accurate time of day, and, furthermore, allows the use of a simple session reflector, making it an attractive alternative to OWAMP. Both OWAMP and TWAMP consist of inter-related control and test protocols, although "TWAMP Light" eliminates the need for the control protocol. OWAMP and TWAMP control protocols run over TCP, while the test protocols run over UDP. The purpose of the control protocols is to initiate, start, and stop test sessions, and for OWAMP to fetch results. The test protocols introduce test packets (which contain sequence numbers and timestamps) along the IP path under test according to a schedule, and record statistics of packet arrival. Multiple sessions may be simultaneously defined, each with a session identifier, and defining the number of packets to be sent, the amount of padding to be added (and thus the packet size), the start time, and the send schedule (which can be either a constant time between test packets or exponentially distributed pseudo-random). Statistics recorded conform to the relevant IPPM RFCs. OWAMP defines the following logical roles: Session-Sender, Session- Receiver, Server, Control-Client, and Fetch-Client. The Session- Sender originates test traffic that is received by the Session- receiver. The Server configures and manages the session, as well as returning the results. The Control-Client initiates requests for test sessions, triggers their start, and may trigger their termination. The Fetch-Client requests the results of a completed session. Multiple roles may be combined in a single host - for example, one host may play the roles of Control-Client, Fetch-Client, and Session-Sender, and a second playing the roles of Server and Session-Receiver. In a typical OWAMP session the Control-Client establishes a TCP connection to port 861 of the Server, which responds with a server greeting message indicating supported security/integrity modes. The Control-Client responds with the chosen communications mode and the Server accepts the modes. The Control-Client then requests and fully describes a test session to which the Server responds with its acceptance and supporting information. More than one test session may be requested with additional messages. The Control-Client then starts a test session and the Server acknowledges. The Session- Sender then sends test packets with pseudorandom padding to the Session-Receiver until the session is complete or until the Control- Client stops the session. Once finished, the Fetch-Client sends a fetch request to the server, which responds with an acknowledgement and immediately thereafter the result data. TWAMP defines the following logical roles: session-sender, session- reflector, server, and control-client. These are similar to the OWAMP roles, except that the Session-Reflector does not collect any packet information, and there is no need for a Fetch-Client. In a typical TWAMP session the Control-Client establishes a TCP connection to port 862 of the Server, and mode is negotiated as in OWAMP. The Control-Client then requests sessions and starts them. The Session-Sender sends test packets with pseudorandom padding to the Session-Reflector which returns them with insertion of timestamps. OWAMP and TWAMP test traffic is designed with security in mind. Test packets are hard to detect because they are simply UDP streams between negotiated port numbers, with potentially nothing static in the packets. OWAMP and TWAMP also include optional authentication and encryption for both control and test packets. 1.8. ITU Recommendation Y.1731 [Y.1731] specifies a set of OAM procedures and related packet data unit (PDU) formats that meet the transport network requirements for OAM. These PDU and procedures address similar requirements to those outlined in [MPLS-TP OAM Reqs]. The PDU and procedures defined in [Y.1731] are described for an Ethernet environment, with the appropriate encapsulation for that environment. However, the actual PDU formats are technology agnostic and could be carried over different encapsulations, e.g. VCCV control channel. The OAM procedures, likewise, could be supported by MPLS-TP nodes just as they are supported by Ethernet nodes. [Y.1731] describes procedures to support the following OAM functions: o Connectivity and Continuity Monitoring - for pro-active mode end- to-end checking o Loopback functionality - to verify connectivity to intermediate nodes in an on-demand mode o Link Trace - provides information on the intermediate nodes of the path being monitored, may be used for fault localization. This is activated in an on-demand mode. o Alarm Indication Signaling - for alarm suppression in case of faults that are detected at the server layer, activated pro- actively. o Remote Defect Indication - as part of the Connectivity and Continuity Monitoring packets, performed pro-actively o Locked Signal - for alarm suppression in case of administrative locking at the server layer. This function is performed pro- actively. o Performance monitoring - including measurement of packet delays both uni and bi-directional (on-demand), measurement of the ratio of lost packets (pro-active), the effective bandwidth that is supported without packet loss, and throughput measurement. The PDU defined in [Y.1731] includes various information elements (fields) including information on the MEG-Level, etc. Addressing of the PDU as defined in [Y.1731] is based on the MAC Address of the nodes, which would need to be adjusted to support other addressing schemes. The addressing information is carried in <Type, Length, Value> (TLV) fields that follow the actual PDU. In the LBM PDU the MAC address is used to identify the MIP to which the message is intended 1.9. Acronyms This draft uses the following acronyms: AC Attachment Circuit ACH Associated Channel Header BFD Bidirectional Forwarding Detection CC-V Continuity Check and Connectivity Verification FEC Forwarding Equivalence Class G-ACH Generic Associated Channel Header LDP Label Distribution Protocol LSP Label Switched Path MPLS-TP Transport Profile for MPLS OAM Operations, Administration, and Maintenance OWAMP One Way Active Measurement Protocol PDU Packet Data Unit PW Pseudowire RDI Remote Defect Indication SLA Service Level Agreement TLV Type, Length, Value TTL Time-to-live TWAMP Two Way Active Measurement Protocol VCCV Virtual Circuit Connectivity Verification 2. Architectural requirements and general principles of operation [MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture and general principles of operations which are evaluated below: o [MPLS-TP OAM Reqs] requires that OAM mechanisms in MPLS-TP are independent of the transmission media and of the client service being emulated by the PW. The existing tools comply with this requirement. o [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM MUST be able to support both an IP based and non-IP based environment. If the network is IP based, i.e. IP routing and forwarding are available, then the MPLS-TP OAM toolset MUST be able to operate by relying on the IP routing and forwarding capabilities. All of the existing MPLS tools (i.e. LSP Ping, VCCV Ping, MPLS BFD, and VCCV BFD) can support this functionality. The Y.1731 toolset does not specifically support this functionality, but rather relies on underlying technologies for forwarding. The forwarding could also be supported over IP, e.g. by using a VCCV extension. Note that some of the MPLS-TP tools such as Alarm Report are very transport oriented and may not support IP functionality. o [MPLS-TP OAM Reqs] requires that MPLS-TP OAM MUST be able to operate without IP functionality and without relying on control and/or management planes. It is required that OAM functionality MUST NOT be dependent on IP routing and forwarding capabilities. Except for the LSP Ping operation of verifying the data-plane vs. the control-plane, the existing tools do not rely on control and/or management plane, however the following should be observed regarding the reliance on IP functionality: * LSP Ping, VCCV Ping, and MPLS BFD make use of IP header (UDP/IP) and do not completely comply with the requirement. In the on-demand mode, LSP Ping also may use IP forwarding to reply back to the source router. This dependence on IP, has further implications concerning the use of LSP Ping as the bootstrap mechanism for BFD for MPLS. There are extensions to LSP-Ping that are under discussion that allow LSP-Ping to restrict replies to the backside of a bidirectional LSP. * VCCV BFD supports the use of PW-ACH encapsulated BFD sessions for PWs and can comply with the requirement. * Y.1731 PDU are technology agnostic and thereby not dependent on IP functionality. These PDU could be carried by VCCV or G-ACH control channels. o [MPLS-TP OAM Reqs] requires that OAM tools for fault management do not rely on user traffic, and the existing MPLS OAM tools and Y.1731 already comply with this requirement. o It is also required that OAM packets and the user traffic are congruent (i.e. OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane ones. * For PWs, VCCV provides a control channel that can be associated with each PW which allows sending OAM packets in band of PWs and allow the receiving end-point to intercept, interpret, and process them locally as OAM messages. VCCV defines different VCCV Connectivity Verification Types for MPLS (like ICMP Ping, LSP Ping and IP/UDP encapsulated BFD and PW-ACH encapsulated BFD). * Currently there is no distinct OAM payload identifier in MPLS shim. BFD and LSP Ping packets for LSPs are carried over UDP/IP and are addressed to the loopback address range. The router at the end-point intercepts, interprets, and processes the packets. [MPLS G-ACH] generalizes the use of the PW ACH and enables provision of control channels at the MPLS LSP and sections levels. This new mechanism would support carrying the existing MPLS OAM messages or the Y.1731 messages at the LSP and the section levels to be transmitted over the G-ACH. o [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM mechanism allows the propagation of AC (Attachment Circuit) failures and their clearance across a MPLS-TP domain * BFD for VCCV supports a mechanism for "Fault detection and AC/PW Fault status signaling." This can be used for both IP/ UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by setting the appropriate VCCV Connectivity Verification Type.This mechanism could support this requirement. Note that in the PWE3 WG there are two proposals regarding how to transmit the AC failures over an ACH that may be applicable to this requirement. o [MPLS-TP OAM Reqs] requires a single OAM technology and consistent OAM capabilities for LSPs, PWs, and Sections. The existing set of tools defines a different way of operating the OAM functions (e.g. LSP Ping to bootstrap MPLS BFD vs. VCCV). Currently, the Y.1731 functionality is defined for Ethernet paths, and the procedures could readily be redefined for the various MPLS-TP path concepts. o [MPLS-TP OAM Reqs] requires allowing OAM packets to be directed to an intermediate point of a LSP/PW. Technically, this could be supported by the proper setting of the TTL value. It is also recommended to include the identifier of the intermediate point within the OAM message to allow the intermediate point to validate that the message is really intended for it. The information can be included in an ACH-TLV according to the definitions in [MPLS-TP ACH TLV]. The applicability of such a solution needs to be examined per OAM function. For details, see below. o [MPLS-TP OAM Reqs] suggests that OAM messages MAY be authenticated. BFD defines support for optional authentication fields using different authentication methods as defined in [BASE BFD]. Other tools should support this capability as well. Y.1731 functionality uses the identification of the path for authentication. Authentication information could be included in an optional TLV field according to the definitions in [MPLS-TP ACH TLV] when not available in the OAM PDU. 2.1. Architectural and Principles of Operation - Recommendations and Guidelines Based on the requirements analysis above, the following guidelines should be followed to create an OAM environment that could more fully support the requirements cited: o Define a generalized addressing scheme that can also support unique identification of the monitored paths (or connections). o Use G-ACH for LSP and section levels. o Define architectural element that is based on LSP hierarchy to apply the mechanisms to segments and concatenated segments. o Apply BFD to these new mechanisms using the control channel encapsulation, as defined above - allowing use of BFD for MPLS-TP independent of IP functionality. This could be used to address the CC-V functionality, described below. o Similarly, LSP Ping could be extended to use only the LSP path (in both directions) without IP Forwarding. Addressing for PW can be included by using the VCCV mechanism. LSP Ping could be used to address the CC-V, Route Tracing, RDI, and Lock/Alarm Reporting functionality cited in the requirements. o The Y.1731 PDU set could be used as a basis for defining the information units to be transmitted over the G-ACH. The actual procedures and addressing schemes would need to be adjusted for the MPLS-TP environment. o Define a mechanism that could be used to idnetify an intermediate point of a path in a unique way, to support the maintenance functions. This addressing should be flexible to allow support for different addressing schemes, and would supplement the TTL exception mechanism to allow an OAM packet to be intercepted by intermediate nodes. Creating these extensions/mechanisms would fulfill the following architectural requirements, mentioned above: o Independence of IP forwarding and routing, when needed. o OAM packets should be transmitted in-band. o Support a single OAM technology for LSP, PW, and Sections. In addition, the following additional requirements can be satisfied: o Provide the ability to carry other types of communications (e.g., APS, Management Control Channel (MCC), Signaling Control Channel (SCC)), by defining new types of communication channels for PWs, Sections, and LSPs. o The design of the OAM mechanisms for MPLS-TP MUST allow the ability to support vendor specific and experimental OAM functions. 3. MPLS-TP OAM Functions The following sections discuss the required OAM functions that were identified in [MPLS-TP OAM Reqs]. 3.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification (CC-V) are OAM operations generally used in tandem, and compliment each other. These functions may be split into separate mechanisms. Together they are used to detect loss of traffic continuity and misconnections between path end-points and are useful for applications like Fault Management, Performance Monitoring and Protection Switching, etc. To guarantee that CC-V can identify misconnections from cross- connections it is necessary that the tool use network-wide unique identifiers for the path that is being checked in the session. 3.1.1. Existing tools LSP Ping provides much of the functionality required for co-routed bidirectional LSPs. As observed above, LSP Ping may be operated in both asynchronous and on-demand mode. Addressing is based on the full FEC identification that provides a unique identifier, and the basic functionality only requires support for the loopback address range in each node on the LSP path. BFD defines functionality that can be used to support the pro-active OAM CC-V function when operated in the asynchronous mode. However, the current definition of basic BFD is dependent on use of LSP Ping to bootstrap the BFD session. Regarding the connectivity functional aspects, basic BFD has a limitation that it uses only locally unique (to each node) session identifiers. VCCV can be used to carry either LSP Ping or BFD packets that are not IP/UDP encapsulated for CC-V on a PW. Note that PW termination/ switching points use only locally unique (to each node) labels. The PW label identifies the path uniquely only at the LSP level. Y.1731 provides functionality for all aspects of CC-V for an Ethernet environment, this could be translated for the MPLS-TP environment. The CCM PDU defined in [Y.1731] includes the ability to set the frequency of the messages that are transmitted, and provides for attaching the address of the path (in the Ethernet case - the MEG Level) and a sequencing number to verify that CCM messages were not dropped. 3.1.2. Gap analysis LSP Ping could be used to cover the cases of co-routed bidirectional LSPs. However, there is a certain amount of computational overhead involved with use of LSP Ping (as was observed in sec 1.1), the verification of the control-plane, and the need to support the loopback functionality at each intermediate node. LSP Ping uses a fully qualified LSP identifier, and when used in conjunction with VCCV would use the PW label to identify the transport path. LSP Ping can be extended to bypass the verification of the control plane BFD could be extended to fill the gaps indicated above. The extension would include: o A mechanism should be defined to carry BFD packets over LSP without reliance on IP functionality. o A mechanism should be defined to bootstrap BFD sessions for MPLS that is not dependent on UDP. o BFD needs to be used in conjunction with "globally" unique identifiers for the path or ME being checked to allow connectivity verfication support. There are two possibilities, to allow BFD to support this new type of identifier - * Change the semantics of the two Discriminator fields that exist in BFD and have each node select the ME unique identifier. This may have backward compatibility implications. * Create a new optional field in the packet carrying the BFD that would identify the path being checked, in addition to the existing session identifiers. o Extensions to BFD would be needed to cover P2MP connections. Use of the Y.1731 functionality is another option that could be considered. The basic PDU for CCM includes (in the flags field) an indication of the frequency of the packets [eliminating the need to "negotiate" the frequency between the end-points], and also a flag used for RDI. The procedure itself would need adaptation to comply with the MPLS environment. An additional option would be to create a new tool that would give coverage for both aspects of CC-V according to the requirements and the principles of operation (see section 2.1). This option is less preferable. 3.1.3. Recommendations and Guidelines Extend LSP Ping to fully support the on-demand Connectivity Verification function resolving the gaps described above. Extend BFD to support proactive Continuity Check & Connectivity Verification (CC-V) resolving the gaps described above. Note that [MPLS BFD] defines a method for using BFD to provide verification of multipoint or multicast connectivity. 3.2. Alarm Reporting Alarm Reporting is a function that is used by an intermediate point in a path to notify the end-points of the path of a fault or defect condition indirectly affecting that path. Such information may be used by the endpoints, for example, to suppress alarms that may be generated by maintenance end-points of the path. This function should also have the capability to differentiate an administrative lock from a failure condition at a different execution level. 3.2.1. Existing tools There is no mechanism defined in the IETF to support this function. Y.1731 does define a PDU and procedure for this functionality. 3.2.2. Recommendations and Guidelines Define a new tool and PDU to support Alarm Reporting. The PDU should be transmitted over a G-ACH. The frequency of transmision after the alarm is raised and the continued frequency until it is cleared should be indicated in the definition. Describe also how the Alarm Reporting functionality may be supported in the control-plane and management-plane. 3.3. Diagnostic A diagnostic test is a function that is used between path end-points to verify bandwidth throughput, packet loss, bit errors, etc. This is usually performed by sending packets of varying sizes at increasing rates (until the limits of the service level) to measure the actual utilization. 3.3.1. Existing tools There is no mechanism defined in the IETF to support this function. [Y.1731] describes a function that is dependent on sending a series of TST packets (this is a PDU whose size can be varied) at differing frequencies. 3.3.2. Recommendations and Guidelines Define a new tool and PDU to support Diagnostic. 3.4. Route Tracing Functionality of route determination is used to determine the route of a connection across the MPLS transport network. [MPLS-TP OAM Reqs] defines that this functionality MUST allow a path end-point to identify the intermediate and end-points of the path. This functionality MUST support co-routed bidirectional paths, and MAY support associated bidirectional and unidirectional p2p paths, as well as p2mp unidirectional paths. Unidirectional path support is dependent on the existence of a return path to allow the original end-point to receive the trace information. 3.4.1. Existing tools LSP Ping supports a trace route function that could be used for bidirectional paths. Support of unidirectional paths would be dependent on the ability of identifying a return path. 3.4.2. Recommendations and Guidelines Extend LSP Ping to support the Route Trace functionality and to address additional options, i.e. PW and p2mp unidirectional LSP. 3.5. Loopback tool Editor's note: In recent discussions a requirement was raised to support multiple maintenance points on a single node and the definition of the Loopback function that would appropriately test theconnectivity of these MP in order to identify fault location. This functionality must be more fully specified in the OAM Framework document before further analysis. 3.6. Lock Instruct The Lock instruct function allows the system to block off transmission of data along a LSP. When a path end-point receives a command, e.g. from the management system, that the path is blocked, the end-point informs the far-end that the path has been locked and that no data should be transmitted. This function is used on-demand. 3.6.1. Existing tools There is no mechanism defined in the IETF to support this function, but LSP Ping could be extended to support this functionality between the path endpoints. Y.1731 does define a PDU and procedure for this functionality. 3.6.2. Recommendations and Guidelines Extend LSP Ping to support Lock instruct. The frequency at which these messages are transmitted until the lock situation is cleared, should be clearly indicated. 3.7. Lock Reporting Lock reporting is used by an intermediate point to notify the end points of a transport path (that the intermediate point is a member of) that an external lock condition exits for this transport path. This function is used proactively. 3.7.1. Existing tools There is no mechanism defined in neither the IETF nor in Y.1731 to support this function. 3.7.2. Recommendations and Guidelines Define a new tool and PDU to support Lock reporting. This tool could be designed similarly to the Alarm Reporting tool (described above), but would need to be initiated by an intermediate point of the transport path. 3.8. Remote Defect Indication Remote Defect Indication (RDI) is used by a path end-point to notify its peer end-point that a defect, usually a unidirectional defect, is detected on a bi-directional connection between them. This function should be supported in pro-active mode. 3.8.1. Existing tools There is no mechanism defined in the IETF to fully support this functionality, however BFD supports a mechanism of informing the far- end that the session has gone down, and the Diagnostic field indicates the reason. Similarly, when LSP Ping is used for a co- routed bidirectional LSP the far-end LER could notify that there was a misconnectivity. In [Y.1731] this functionality is defined as part of the CC-V function as a flag in the PDU. 3.8.2. Recommendations and Guidelines Extend BFD (which is recommended to be used for proactive CC-V) to transmit the signal of Remote Defect Indication without disrupting the CC-V functionality. Such an extension could be similar to that suggested by the ITU recommendation. 3.9. Client Failure Indication Client Failure Indication (CFI) function is used to propagate an indication of a failure to the far-end sink when alarm suppression in the client layer is not supported. 3.9.1. Existing tools There is a possibility of using the BFD over VCCV mechanism for "Fault detection and AC/PW Fault status signaling". However, there is a need to differentiate between faults on the AC and the PW. In the PWE3 WG there are some proposals regarding how to transmit the CFI over an ACH. 3.9.2. Recommendations and Guidelines Use PWE3 tool to propagate Client Fail Indication via an ACH. 3.10. Packet Loss Measurement Packet Loss Measurement is a function that is used to verify the quality of the service. This function indicates the ratio of packets that are not delivered out of all packets that are transmitted by the path source. There are two possible ways of determining this measurement - o Using OAM packets, it is possible to compute the statistics based on a series of OAM packets. This, however, has the disadvantage of being artificial, and may not be representative since part of the packet loss may be dependent upon packet sizes. o Sending delimiting messages for the start and end of a measurement period during which the source and sink of the path count the packets transmitted and received. After the end delimiter, the ratio would be calculated by the path OAM entity. 3.10.1. Existing tools There is no mechanism defined in the IETF to support this function. [Y.1731] describes a function that is based on sending the CCM packets [used for CC-V support (see sec 3.1)] for proactive support and specialized loss-measurement packets for on-demand measurement. These packets include information (in the additional TLV fields) of packet counters that are maintained by each of the end-points of a path. These counters maintain a count of packets transmitted by the ingress end-point and the count of packets received from the far-end of the path by the egress end-point. 3.10.2. Recommendations and Guidelines One possibility is to define a mechanism to support Packet Loss Measurement, based on the delimiting messages. This would include a way for delimiting the periods for monitoring the packet transmissions to measure the loss ratios, and computation of the ratio between received and transmitted packets. A second possibility would be to define a functionality based on the description of the loss-measurement function defined in [Y.1731] that is dependent on the counters maintained, by the MPLS LSR (as described in [RFC3813], of received and transmitted octets. Define a new PDU for the message that utilizes G-ACH. This option appears more suitable for performance monitoring statistics, which in transport applications are based on the continuous monitoring of the traffic interested (100 ms gating). 3.11. Packet Delay Measurement Packet Delay Measurement is a function that is used to measure one- way or two-way delay of a packet transmission between a pair of the end-points of a path (PW, LSP, or Section). Where: o One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. o Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed atthe packet's destination node. Similarly to the packet loss measurement this could be performed in one of two ways - o Using OAM packets - checking delay (either one-way or two-way) in transmission of OAM packets. May not fully reflect delay of larger packets, however, gives feedback on generalservice level. o Using delimited periods of transmission - may be too intrusive on the client traffic. 3.11.1. Existing tools There is no mechanism defined in the IETF toolset that fulfills all of the MPLS-TP OAM requirements. [Y.1731] describes a function in which specific OAM packets are sent with a transmission time-stamp from one end of the managed path to the other end (these are transparent to the intermediate nodes). The delay measurement is supported for both one-way and two-way measurement of the delay. It should be noted that the functionality on the one-way delay measurement is dependent upon a certain degree of synchronization between the time clocks of the two-ends of the transport path. 3.11.2. Recommendations and Guidelines Define a mechanism that would support Packe Delay Measurement, based on the procedures defined in [Y.1731]. The mechanism should be based on measurement of the delaylayers in transmission and reception of OAM packets, transmitted in-band with normal traffic. Define an appropriate PDU that would utilize the G-ACH. 4. Recommendations As indicated above, LSP-Ping could easily be extendedorder to support some of the functionality between the path end-points and between an end- point of a path and an intermediate point. BFD could also be extendedimprove their ability to support some of the functions between the end-points of a path. Some of the OAM functions defined in [Y.1731] (especially for performance monitoring) could also be adapted. The guidelines that are used in this document are as follows: o Re-use/extend existing IETF protocols wherever applicable. o Define new message format for each of the rest of the OAM functions, which are alignedservices with the ACHguaranteed and ACH-TLV definitions,strict Service Level Agreements (SLAs) while reducing their operational costs. [MPLS-TP Reqs] in general, and includes only relevant information. o Adapt Y.1731 functionality where applicable (mainly for performance monitoring). The recommendations on the MPLS-TP[MPLS-TP OAM tools are as follows: o DefineReqs] in particular define a maintenance entity that could be applied both to LSPs and PWs that would support managementset of a sub-path. This entity should allowrequirements for transmission of traffic by means of label stacking and proper TTL setting. o Extend the control and the management planes to support the configuration of theOAM maintenance entitiesfunctionality in MPLS-Transport Profile (MPLS-TP) for MPLS-TP Segments, Label Switched Paths (LSPs) (network infrastructure) and the setPseudowires (PWs) (services). One of functions to be supported by these entities. o Define a mechanism that would allowthe unique addressingmandates of the elements that need to be monitored, e.g., the connections, end- points,joint (IETF and intermediate pointsITU-T) MPLS-TP work-item is the objective of developing a path. This mechanism needs to be flexible enoughTransport Profile is to support different addressing schemes, e.g. IP addresses, NSAP, connection names. As pointed out above, LSP Ping uses the full FEC identifier forbase the LSP - this could easily be applied to Section OAM since this would be considered as a stacked LSP. o The appropriate assignment of network-wide unique identifiers for transport paths, needed to support connectivity verification, should be considered. o Extendtoolset on existing MPLS tools to disengage from IP forwarding mechanisms. o Extend BFD to support the proactive CC-V functionalities. The extensions should address the gaps described above. o Extend LSP Ping to support the on-demand Connectivity Verification functionality. The extensions should address the gaps described above. o Define a new PDU which will be transmitted over G-ACH to support the Alarm Reporting functionality for data-plane implementations. Describe how Alarm Reporting can be supported by a control-plane and by a management-plane. o Define a new PDU which will be transmitted over G-ACH to support the Lock Reporting functionality. Use the same procedures as for Alarm Reporting. o Extend BFD to supporttechnologies. In addition, [MPLS-TP Reqs] indicates the Remote Defect Indication (RDI) functionality. The extensions should addressneed for the gaps described above. o Extend LSP-PingOAM toolset for MPLS-TP to support the Route tracing functionality.be fully interoperable with existing MPLS OAM tools. The extensions should address the gaps described above. o Extend LSP-Pingpurpose of this document is to supportoutline the Lock Instruct functionality between end-pointsrecommendations of a path. The extensions should addressthe gaps described above. o Use PWE3 tool to transmit Client Fault Indication (CFI) via ACH. There are already some proposals inMPLS-TP design team and confirmed by the PWE3 WG. o Define a new PDU which willworking group for the toolset that should be transmitted over G-ACHdefined to support the Packet Loss Measurement functionality. Basefulfill the OAM functionality requirements as documented in [MPLS-TP OAM Reqs] and [MPLS-TP OAM Frwk]. Based on the procedures defined in Y.1731. o Define a new PDU which be transmitted over G-ACHprinciples cited above, it was determined to support the Packet Delay Measurement functionality. Basebase the functionalityMPLS-TP OAM toolset on the proceduresfollowing existing MPLS tools: o LSP-Ping as defined in Y.1731. For one-way delay measurement define mechanisms to ensure a certain degree of synchronization between the time clocks of the two-ends of the transport path.[LSP Ping]. o Define a new PDU whichBidirectional Forwarding Detection (BFD) as defined in [BASE BFD] and refined in [MPLS BFD]. o ITU-T OAM for Ethernet toolset as defined in [Y.1731] this will be transmitted over G-ACH to supportused for functionality guidelines for the Diagnostic functionality. o Theperformance measurement tools that are not currently supported in MPLS. It should be noted that certain extensions and adjustments may have the capabilitybe made to authenticatethe messages. The information may be carriedexisting MPLS tools, in a G-ACH TLV. 5. MPLS-TP OAM Documents Organization The following paragraphs list the set of documents necessaryorder to conform to coverthe OAM functionalities analyzed above. This compilationtransport environment and the requirements of documents is oneMPLS-TP. 1.2. Organization of the outcomesdocument Section 2 of the MEAD team discussions that took place during IETF75 in Stockholm. It should be noted that the variousdocument titles listed here may not reflectprovides references to the draft titlesbasic OAM tools that will be chosen atare provided for MPLS-TP OAM. Section 3 outlines the timedifferent tools that the draftsare written, but they serve just as a topic pointer from the current analysis. 5.1. Document 1: "Encapsulation of BFDrequired for MPLS-TP OAM and LspPing in ACH" The scope ofreferences the document is todocuments that will define the usage of LSP Ping and BFD in both IP and IP-less environments. As described inappropriate tools based on the principles outlined above. 1.3. Contributing Authors Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi (Alcatel Lucent), Huub van Helvoort (Huawei) 1.4. Acronyms This draft uses the following paragraphs,acronyms: ACH Associated Channel Header BFD Bidirectional Forwarding Detection CC-V Continuity Check and Lsp Ping need to be extended in order to be compliant withConnectivity Verification G-ACH Generic Associated Channel Header LSP Label Switched Path MPLS-TP Transport Profile for MPLS OAM Operations, Administration, and Maintenance PW Pseudowire RDI Remote Defect Indication SLA Service Level Agreement TLV Type, Length, Value VCCV Virtual Circuit Connectivity Verification 2. Basic OAM infrastructure functionality [MPLS-TP OAM Reqs]. However, this document should be focusedReqs] defines a set of requirements on the existing Lsp PingOAM architecture and BFD, without necessarily referring to their extended versions. The draft "nitinb-mpls-tp-lsp-ping-bfd-procedures" will be considered as the starting point for this definition. In particular, the following sections will be taken into account for the scope:general principles of operations which are evaluated below: o nitinb-mpls-tp-lsp-ping-bfd-procedures section 2 ("LSP-Ping extensions") for addressing the "Lsp Ping encapsulation[MPLS-TP OAM Reqs] requires that OAM mechanisms in ACH" o nitinb-mpls-tp-lsp-ping-bfd-procedures section 5 ("Running BFD overMPLS-TP LSPs") for addressingare independent of the "BFD encapsulation in ACH" 5.2. Document 2: "Extended BFD" The scopetransmission media and of the document isclient service being emulated by the PW. o [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM must be able to definesupport both an IP based and non-IP based environment. If the BFD extensionnetwork is IP based, i.e. IP routing and behavior to meetforwarding are available, then the requirements forMPLS-TP proactive Continuity Check and Connectivity Verification functionalityOAM toolset should rely on the IP routing and forwarding capabilities. On the RDI functionality as definedother hand, in environments where IP functionality is not available, the OAM tools must still be able to operate without dependence on IP forwarding and routing. o [MPLS-TP OAM Reqs]. The document will likely takeReqs] requires that all OAM protocols support identification information, at least in the name "draft-asm-mpls-tp-bfd-cc-cv-00"form of IP addressing structure and willbe formed by the merging of the following two drafts: o draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rd o draft-boutros-mpls-tp-cc-cv-01.txt 5.3. Document 3: "Extended LSP Ping" The scope of the document isextensible to define:support additional identification schemes. o A place holder for On Demand Connectivity Verification if LSP Ping needs to be enhanced overIt is also required that OAM packets and abovethe encapsulations changes (defined in Document 1 "Encapsulation of BFD and LSP Ping in ACH"). o Usage of LSP Ping with MIPsuser traffic are congruent (i.e. OAM packets are transmitted in-band) and MEPs, whichthere is partially covereda need to differentiate OAM packets from user-plane ones. Inherent in nitinb-mpls-tp-lsp-ping-bfd-procedures.this requirement is the principle that MPLS-TP OAM be independent of any existing control-plane, although it should not preclude use of the control-plane functionality. o Route Trace. This topic has already been partially covered in "draft-boutros-mpls-tp-path-trace-00"[MPLS-TP OAM Reqs] requires a single OAM technology and "nitinb-mpls-tp-lsp- ping-bfd-procedures", which will be considered as starting pointconsistent OAM capabilities for the Route Trace functionality included in Document 3. The Route Trace section should also cover these aspects: * LSP Ping Loose ends. This section will describe what to do when receiving an LSP Ping with MIPLSPs, PWs, and MEP ids. * In an IP-Less environment Route Trace works only in co-routed bidirectional LSP. * In Y.1731Sections. o [MPLS-TP OAM Reqs] requires allowing OAM packets to be directed to an intermediate point of a LSP/PW. The following comprise the CV function is separate fromdocument-set that addresses the Route Trace function, it should be captured how LSP Ping works for Route Trace using TTL. 5.4. Document 4: "Extensions for Lock Instruct" A newbasic requirements listed above: o The [MPLS-TP OAM Frwk] document describingdescribes the LSP Ping extensionsarchitecural framework for conformance to accomplishthe Lock Instruct desired behavior is needed. Some material useful for this scope can be found in "draft-boutros-mpls-tp-loopback-02". 5.5. Document 5: "AIS and Lock Reporting" A new document is need forbasic requirements listed above. It also defines the definition ofbasic relationships between the AISMPLS structures, e.g. LSP, PW, and Lock Reporting, howeverthe document definition has been temporarily deferred bystructures necessary for OAM functionality, i.e. the MEAD team. Therefore this paragraph will be updated in future versions. 5.6. Document 6: "Client Fault Indication" A new document describing Client Fault Indication procedure needs to be defined. The following two drafts indicating a client fault indication transported across MPLS-TP network will be comparedManaged Entity Group, its End-points, and merged in the new document:Intermediate Points. o "draft-he-mpls-tp-csf", which describes a tool to propagate a client failure indication across an MPLS-TP network in caseThe [MPLS G-ACH] document specifies the propagationuse of failure status inthe client layerMPLS-TP in- band control channel. This is not supported. o "draft-martini-pwe3-static-pw-status", which describesmodeled after the usage of PW associatedVCCV channel to signal PW status messagesdescribed in case a static PW is used without a control plane[PW ACH] and allows transporting the OAM messages congruently with the data traffic while allowing the required identification of the packets. It is worth notingexpected that a Client Failure Indication is used ifall of the client does not support its ownOAM (IP and MPLS as clients use their own). It has been also agreedprotocols will be used in conjunction with this Generic Associated Channel. o The [MPLS-TP ACH TLV] document specifies a basic set of TLV fields that CFI iscould be used on PW and not on client directly mapped on LSP MPLS-TP. 5.7. Document 7: "Packet Loss" A newby different OAM messages, in conjunction with the Generic Associated Channel, to supply the additional parameter values necessary for the proper functionality. o The [MPLS TP Idents] document needs to be defined in orderaddresses the need of MPLS-TP to describe a stand alone toolsupport different addressing spaces. This document describes different formats for Packet Loss measurementsaddresses that can work both proactively and on demand. The tool willcould be functionally based on Y.1731. 5.8. Document 8: "Packet Delay" A new document needsused to be defined aboutidentify the Packet Delay measurement which will be based on Y.1731 fromtransport entities in the functionality point of view. Moreover,network and referenced by the different OAM protocols. 3. MPLS-TP OAM Functions The following sections discuss the required OAM functions that were identified in [MPLS-TP OAM Frwk] needs to be updatedReqs] and expanded upon in order[MPLS-TP OAM Frwk]. 3.1. Continuity Check and Connectivity Verification Continuity Check and Connectivity Verification (CC-V) are OAM operations generally used in tandem, and compliment each other. These functions are generally run proactively, but may also be used on-demand, either due to clarify the functionality behavior expected from this tool. 5.9. Document 9: "Diagnostic Tests" Onebandwidth considerations or more new documents are neededfor diagnoses of a specific condition. Proactively [MPLS-TP OAM Reqs] states that the tools definition for Diagnostic Tests. However,function should allow the documents definition has been temporarily deferred byMEPs to monitor the MEAD team until a clearer definitionliveness and connectivity of "diagnostic test"a transport path. In on-demand mode, this function should support monitoring between the MEPs and, in addition, between a MEP and MIP. The [MPLS-TP OAM Reqs]. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations This document does not by itself raise any particular security considerations. 8. Acknowledgements The authors wish to thankFrwk] highlights the MEAD teamneed for their review and proposed enhancementsthe CC-V messages to include unique identification of the text. Appendix A. Proactive CC and CV BFD tool analysis This appendixMEG that is focused on analyzing possible solutionsbeing monitored and evaluating their pros&cons for defining an MPLS-TP OAM mechanism BFD based,to meetthe requirements for proactive Continuity CheckMEP that originated the message. The function, both proactively and Connectivity Verification functionality as requiredin [MPLS-TP OAM Reqs]. The BFD tool needson-demand mode, need to be extended for the CV functionalitytransmitted at regular rates pre- configured by the addition of a unique identifier in order to meetoperator. 3.1.1. Documents for CC-V tools [Pro CC-V] defines the requirements. Proactive Continuity Check (CC) and Continuity Verification (CV) function areBFD extensions that will be used for proactive CC-V applications. While [Demand CV] provides the LSP-Ping extensions that will be used togetherto detect lossimplement on-demand Connectivity Verification. Both of continuity (LOC), unintended connectivity between two MEs (e.g. mismerging or misconnection) as well as unintended connectivity within the MEthese tools will be used together with an unexpected MEP. It MUST operate both in bidirectional p2p and in unidirectional p2mp connection. The mechanism MUST foresee the configuration ofthe transmit frequency. The mechanismbasic tools mentioned above in section 2 3.2. Remote Defect Indication Remote Defect Indication (RDI) is RECOMMENDED be the same for LSP, (MS-)PW and Section (Seeused by a path end-point to report to its peer end-point that a defect is detected on a bi-directional connection between them. [MPLS-TP OAM Reqs]) Appendix A.1. Possible Solution Several solutions have been analyzed: 1. DefineReqs] points out that this function may be applied to a new BFD version (BFDv2)unidirectional LSP only if there a return path exists. [MPLS-TP OAM Frwk] points out that extendsthis function is associated with the current BFD (BFDv1) to support also CV functionality.proactive CC-V function 3.2.1. Documents for RDI The new[Pro CC-V] document includes and extension for BFD version can be obtained by: * changingthat would include the semantic of MY discriminator and Your discriminator fields [BASE BFD], * adding a new globally unique source MEP ID fieldRDI indication in the BFD packet for the CV functionalityformat, and a specification of how this indication is to the existing session identifier. 2. Define two separate tools, running with two different ACH encapsulations (i.e. two different ACH channel types): * the current BFD with only CCbe used. 3.3. Route Tracing [MPLS-TP OAM Reqs] defines that there is a need for functionality however profiled in behaviorthat would allow a path end-point to meetidentify the CC MPLS-TP requirement; *intermediate and end-points of the path. This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and sections, however, unidirectional paths may be supported only if a new toolreturn path exists. 3.3.1. Documents for Route Tracing The [Demand CV] document that meet allspecifies the LSP-Ping enhancements for MPLS-TP OAM proactive CV requirement. The new tool can be: 1. basedon-demand Connectivity Verification includes information on current BFD; 2. an extension ofthe ACH encapsulationuse of LSP-Ping for the current BFD; 3. a new tool like Y.1731 CCM; All analyzed solutions imply extensionroute tracing of CV types, foreseen by [PW VCCV] yet extended by [VCCV BFD], in order to include thea MPLS-TP OAM mechanism too. Thistransport path. 3.4. Alarm Reporting Alarm Reporting is due to the facta function used by an intermediate point of a path, that VCCV also includes mechanisms for negotiatingbecomes aware of a fault on the control channel and connectivity verification (i.e. OAM functions) between PEs. Appendix A.2. Backward compatibility For backward compatibility, it is possiblepath, to report to runthe current BFD that supports only CC functionality on some transport paths andend-points of the new tool that supports CC and proactive CV functionality on other transport paths. In any case only one tool forpath. [MPLS-TP OAM instanceFrwk] states that this may occur as a result of a defect condition discovered at time, configurable by operator, can run. A MEPa server sub- layer. This generates an Alarm Indication Signal (AIS) that continues until the fault is configuredcleared. The consequent action of this function is detailed in [MPLS-TP OAM Frwk]. 3.4.1. Documents for Alarm Reporting MPLS-TP defines a new protocol to support proactive CVaddress this functionality MUST be capable to receive existing BFD packets (encapsulated with GAL/ G-ACH or PW-ACH)that supports only CC functionality and MUST consider them as an unexpected packet, i.e. detect a misconnection defect and vice versa. The contextis documented in [Fault Mng]. This protocol uses all of MPLS-TPthe basic mechanisms detailed in Section 2. 3.5. Lock Reporting Lock reporting, defined in [MPLS-TP OAM packetsReqs], is based on MPLS label and G-ACH, eliminating in the BFD the need to exchange Discriminator values. An MPLS-TP node that desiressimilar to interoperate with a current BFD can applythe same discriminator field semantic asAlarm Reporting function described in [BASE BFD] or: oabove. It MUST set the My discriminator fieldis used by an intermediate point to a nonzero value (it can be a fixed value); o It MUST reflect backnotify the received valueend points of My discriminator field into the transmitted Your discriminator field, or set ita transport path that an administrative lock condition exists for this transport path. 3.5.1. Documents for Lock Reporting MPLS-TP defines a new protocol to zero ifaddress this functionality that valueis unknown. Appendix A.3. Definitiondocumented in [Fault Mng]. This protocol uses all of BFDv2 Common to both solutionsthe basic mechanisms detailed in this section are the following considerations: oSection 2. 3.6. Diagnostic The Channel Type field of the G-ACH[MPLS-TP OAM Reqs] indicates that there is the one proposed by [VCCV BFD], i.e. 0x0007, indicating the raw BFD control packet; oneed to provide a OAM function that would enable conducting different diagnostic tests on a PW, LSP, or Section. The version number[MPLS-TP OAM Frwk] provides two types of the protocol needs to be updated to protocol version 2 respectspecific tests to protocol version 1 defined in [BASE BFD]. Appendix A.3.1. New semantic for Discriminator fields A possible BFD extension canbe obtained changing the semantic ofused through this functionality: o Throughput Estimation - allowing the two 32 bit fields, My Discriminator and Your Discriminator,provider to form a one 64 bit field carrying the globally unique MEP Identifier. One ofverify the disadvantagesbandwidth/throughput of this solutiona transport path. This is on the too limited number of octets available for the globally unique MEP ID field:an out-of- service tool, that doesn't allow the possibility to have different formatuses special packets of ME identifier. Appendix A.3.2. New MEP ID field This solution adds the new field required for the CV functionality, i.e. a globally unique MEP Identifier section, aftervarying sizes to test the mandatory sectionactual bandwidth and/or throughput of a BFD control packet and beforethe optional Authentication section. The advantages ofpath. o Data-plane loopback - this solution areout-of-service tool that causes all traffic that reaches the discriminator behavior oftarget node, either a MEP or MIP, to be looped back to the current BFD protocol asoriginating MEP. For targeting MIPs, a corouted bi-directional path is required. 3.6.1. Documents for Diagnostic Testing These diagnostic functions are being defined in [BASE BFD] is unchanged and on the variable lengtha merge of existing separate individual drafts. The merged document will define a new G-ACH based protocol message that addresses the MEP ID Section. Appendix A.4. Two different ACH encapsulationThroughput Estimation tool, and also provide various flavors of OAM toolloopback functionality. 3.7. Lock Instruct The current BFD, with only CC functionality,Lock Instruct function is encapsulated in the G-ACh using as Channel type code point the 0x0007 value as described in [VCCV BFD]. This mechanism can be also extendedan administrative control tool that allows a path end-point to Section OAM and LSP OAM. In orderinstruct its peer end-point to meetlock the MPLS-TP OAM proactive CV requirement, a newpath. The tool hasis necessary to be introduced, encapsulated into the G-ACh with a new channel type code point. Commonsupport single-side provisioning for administartive locking, according to all solutions detailed below are. This function is used on- demand. 3.7.1. Documents for Lock Instruct Work is being done on a document that will specify the following G-ACh format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CC-CV proactive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1:new ACH Encapsulation - first nibble: setbased protocol format for this tool. 3.8. Client Failure Indication Client Failure Indication (CFI) is defined in [MPLS-TP OAM Reqs] to 0001ballow the propagation information from one edge of the network to indicate a channel associated with a PW, a LSP orthe other. The information concerns a Section; - Version and Reserved fields are setdefect to 0; - G-ACH Channel Type field witha new TBD code point meaning "MPLS-TP CC-CV proactive" indicatingclient, in the case that the client does not support alarm notification. 3.8.1. Documents for CFI Work is being done on a document that will specify the messagenew ACH based protocol format for this tool. 3.9. Packet Loss Measurement Packet Loss Measurement is an MPLS-TPrequired, by [MPLS-TP OAM CC-CV proactive message. The value MUST be assigned The sections below describe the formatReqs] to provide a quantification of the different possible new tool. Appendix A.4.1. New tool basedpacket loss ratio on current BFD A new tool can be obtained introducinga globally unique MEP Identifier TLV betweentransport path. This is the ACH andratio of the current BFD (defined in [BASE BFD]) Control packet. The benefitnumber of this solution isuser packets lost to maintainthe basic state machine and protocol versiontotal number of BFD asuser packets during a defined in [BASE BFD] and [bfdMultipoint]; considerations on the optional Authentication Section is described in section Appendix A.7. Appendix A.4.2. New tool based ontime interval. To employ this function, [MPLS-TP OAM Frwk] defines that the extended BFD The solutions and considerations aretwo end-points of the sametransport path should exchange counters of what describedmessages transmitted and received within a time period bounded by loss-measurement messages. The framework warns that there may be small errors in section Appendix A.3.2 exceptthe ACH Channel type code, rather thancomputation that result from various issues. 3.9.1. Documents for Packet Loss Measurement The [Loss-Delay] describes the Version field, distinguishes between existing BFD (supporting CC)protocol formats and procedures for using the new tools (supporting both CC&CV).tool. The Version field in this case is set to 0 (thistool logic is based on the first version for this tool). Appendix A.4.3. New tool like Y.1731 CCM To be inserted Appendix A.5. Remote Defect Indication Remote Defect Indication (RDI)behavior of the parallel function described in [Y.1731]. 3.10. Packet Delay Measurement Packet Delay Measurement is used bya MEP to notify its peer MEPfunction that a defect is detected on a bi-directional connection between them). RDIis onlyused for bidirectional connections and is associated with proactive CC & CV packet generation.[MPLS-TP OAM Frwk] The Diagnostic (Diag) fieldto measure one- way or two-way delay of a packet transmission between a pair of the Current BFD can be used for this functionality. However, there isn'tend-points of a total correspondence amongpath (PW, LSP, or Section), as described in [MPLS-TP OAM Reqs]. Where: o One-way packet delay is the values foreseen by [BASE BFD] andtime elapsed from the defect conditions detectedstart of transmission of the first bit of the packet by a source node until the proactive CC-CV tool that requirereception of the RDI function. A solution could be that any defectlast bit of that requires the RDI information being sent topacket by the peer MEPdestination node. o Two-way packet delay is encoded in the Diagnostic (Diag) field withthe value 1 (corresponding totime elapsed from the "Control Detection Time Expired" in [BASE BFD]. The value 0 indicates RDI condition has been cleared. Forstart of transmission of the solution in section Appendix A.4.3 , RDI is foreseen infirst bit of the packet format withby a single bit. Appendix A.6. Point to Multipoint transport paths Solution described in section Appendix A.4.3 is valid for both bidirectional and unidirectional connection: in unidirectional connection onlysource MEP is enabled only to generate CC/CV OAM packets and sink MEP is enabled only to receive CC/CV OAM packets. The BFD tool has a straightforward state machine for bidirectional path. Anywaynode until the behavior and state machine need to be modified forreception of the unidirectional connection; thislast bit of the loop-backed packet by the same source node, when the loopback is described in [bfdMultipoint]. Appendix A.7. Security Considerations Base BFD [BASE BFD] foresees an optional authentication section; that can be extended even toperformed at the packet's destination node. [MPLS-TP OAM Frwk] describes how the tool proposedcould be performed (both in this document. Authentication methodsproactive and on-demand modes) for either one-way or two-way measurement. However, it warns that require checksum calculation onthe outgoing packet must extendone-way delay option requires precise time synchronization between the end-points. 3.10.1. Documents for Delay Measurement The [Loss-Delay] describes the protocol formats and procedures for using the checksum eventool. The tool logic is based on the ME Identifier Section. This is possible but seems uncorrelated withbehavior of the solution proposed in section Appendix A.4.1parallel function described in [Y.1731]. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this case it couldsection may be betterremoved on publication as an RFC. 5. Security Considerations This document does not by itself raise any particular security considerations. 6. Acknowledgements The editors wish to usethank the simple password authentication method. It is also worth noticing thatMPLS-TP Design Team members, from both the interactions between authenticationIETF and connectivity verification need further analysis. 9.ITU-T leadership teams, in formulating the recommendations documented here. In particular, we would like to thank Loa Andersson, Huub van Helvoort, and the Area Directors for their suggestions and enhancements to the text. 7. Informative References [RFC 2119] Bradner, S., "Internet Control Message Protocol", BCP 14, RFC 2119, March 1997. [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, Sept 1981.[LSP Ping] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.[BASE BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", ID draft-ietf-bfd-base-09.txt,RFC 5880, February 2009. [MPLS BFD] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", ID draft-ietf-bfd-mpls-07.txt,RFC 5884, June 2008. [VCCV BFD] Nadeau, T.[MPLS TP Idents] Bocci, M. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)",G. Swallow, "MPLS-TP Identifiers", ID draft-ietf-pwe3-vccv-bfd-07.txt, February 2008. [bfdMultipoint] Katz, D. anddraft-ietf-mpls-tp-identifiers-01.txt, March 2010. [Pro CC-V] Allan, D. Ward, "Bidirectional Forwarding Detection for Multipoint Networks", ID draft-katz-ward-bfd-multipoint-02.txt, February 2009. [P2MP LSP Ping] Nadeau, T.and A. Farrel, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008. [MPLS LSP Ping] Bahadur, N.G. Swallow, "Proactive Connection Verification, Continuity Check and K. Kompella, "MechanismRemote Defect indication for performing LSP-Ping overMPLS tunnels",Transport Profile", ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00,draft-ietf-mpls-tp-cc-cv-rdi-00.txt, June 2008. [RFC4656] Shalunov,2010. [Demand CV] Bahadur, N., Aggarwal, R., Boutros, S., Teitelbaum, B., Karp, A., Boote, J.,and M. Zekauskas, "A One-way Active Measurement Protocol", RFC 4656, September 2006. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K.,E. Gray, "MPLS on-demand Connectivity Verification, Route Tracing and J. Babiarz, "A Two-Way Active Measurement Protocol", RFC 5357, Oct 2008.Adjacency Verification", ID draft-ietf-mpls-tp-on-demand-cv-00, June 2010. [MPLS-TP OAM Reqs] Vigoureux, M., Betts, M., and D. Ward, "Requirements for OAM in MPLS Transport Networks", ID draft-ietf-mpls-tp-oam-requirements-01,draft-ietf-mpls-tp-oam-requirements-05, April 2009. [MPLS-TP OAM Frwk] Busi, I. and B.I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM Framework and Overview", ID draft-ietf-mpls-tp-oam-requirements-01, March 2009.draft-ietf-mpls-tp-oam-framework-07, July 2010. [MPLS-TP Reqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, "Requirements for the Trasport Profile of MPLS", ID draft-ietf-mpls-tp-requirements-06, April 2009. [MPLS G-ACH] Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic Associated Channel", RFC 5586, June 2009. [MPLS-TP ACH TLV] Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and D. Ward, "Definition of ACH TLV Structure", ID draft-ietf-mpls-tp-ach-tlv-00, June 2009. [RFC3813] Srinivasan, C., Viswanathan,[Fault Mng] Swallow, G., Fulignoli, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)M. Vigoureux, "MPLS Fault Management Information Base (MIB)", RFC 3813, June 2004.OAM", ID draft-ietf-mpls-tp-fault-00, March 2010. [Loss-Delay] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for the MPLS Transport Profile", ID draft-frost-mpls-tp-loss-delay-00, April 2010. [Y.1731] International Telecommunications Union - Standardization, "OAM functions and mechanisms for Ethernet based networks", ITU Y.1731, May 2006. Authors' Addresses Nurit Sprecher (editor)Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: email@example.com Huub van Helvoort (editor) Huawei Kolkgriend 38, 1356 BC Almere Netherlands Phone: +31 36 5316076 Email: firstname.lastname@example.orgElisa Bellagamba Ericsson 6 Farogatan St Stockholm, 164 40 Sweden Phone: +46 761440785 Email: email@example.com Yaacov Weingarten Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Phone: +972-9-775 1827 Email: firstname.lastname@example.org