Pseudo-Wire Edge-to-Edge (PWE3) Working Group Simon Delord Internet Draft Uecomm draft-delord-pwe3-oam-applications-02.txt Expires April 2006 Philippe Niger France Telecom Yuichi Ikejiri Yuichiro Wada NTT Deborah Brungard ATT Alain Vedrenne Equant Lei Zhu Sprint Kenji Kumaki KDDI Vasile Radoaca Consultant Dinesh Mohan Nortel Ali Sajassi Cisco Systems October 2005 PWE3 Applications & OAM Scenarios draft-delord-pwe3-oam-applications-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Delord, et. al. Expires April 2006 [Page 1] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document provides requirements and a framework for PWE3 Operation Administration and Maintenance (OAM). It extends the PWE3 architecture reference model by including multi-segment Pseudo Wires (PWs) and also a detailed model of the access portion of the network. This document targets to provide applicability guidelines for the on going OAM work by describing different implementation solutions and detailing the Pros and Cons of each solution. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 Table of Contents STATUS OF THIS MEMO...................................................1 ABSTRACT..............................................................2 1. OVERVIEW...........................................................3 1.1. Terminology......................................................4 1.2. General considerations...........................................4 2. EXTENSION TO THE ARCHITECTURE REFERENCE MODEL......................6 2.1. PWE3 Architecture Reference Model................................6 2.2. Framework extension based on the access service and layered model 6 3. PWE3 OAM FRAMEWORK & REQUIREMENTS..................................8 3.1. PWE3 OAM Framework...............................................9 3.1.1. OAM Domains....................................................9 Delord, et. al. Expires April 2006 [Page 2] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 3.1.2. Propagation of information between OAM Domains.................9 3.2. PW OAM Requirements..............................................9 3.2.1. Generic Requirements..........................................10 3.2.2. Specific Requirements.........................................11 4. PWE3 APPLICATIONS & OAM SCENARIOS.................................15 4.1. Service Supervision.............................................15 4.1.1. E2E Service Supervision.......................................16 4.1.2. Segment Supervision...........................................19 4.2. Application to network scenarios................................21 4.2.1. Homogenous Services...........................................21 4.2.2. Heterogeneous Services........................................25 5. ACKNOWLEDGMENTS...................................................26 6. SECURITY CONSIDERATIONS...........................................27 7. NORMATIVE REFERENCES..............................................27 8. INFORMATIVE REFERENCES............................................27 9. FULL COPYRIGHT STATEMENT..........................................27 10. AUTHORS' ADDRESSES...............................................28 11. APPENDIXES.......................................................29 11.1. Detailed description of each layer of the model................29 11.1.1. Network Layer................................................29 11.1.2. E2E SP Layer.................................................29 11.1.3. Customer Layer...............................................31 12. IPR Notice.......................................................31 1. Overview The purposes of this document are the following: . extend the PWE3 architecture reference model by including a detailed model of the multi-segment Pseudo Wire (PW) OAM . extend the PWE3 architecture reference model by including a detailed model of the access portion of the network . provide additional requirements as well as a framework for PWE3 Operation Administration and Maintenance (OAM) . to provide applicability guidelines for the on going OAM work by describing different implementation solutions The following documents were taken in consideration for the background of this work: . [L2VPN OAM FWK] provides framework and requirements for L2VPN services . [MH-PW Req] introduces OAM requirements for MH-PWs Delord, et. al. Expires April 2006 [Page 3] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 . [OAM Message Mapping] specifies the mapping of defect states between a PW and the Attachment Circuits (AC) of the end-to-end emulated service for an homogeneous service . [VPWS Iwk] specifies the mapping of defect states between a PW and ACs of the end-to-end emulated service for an heterogeneous service Additional documents that are related to this work are: . [VCCV] which describes how to monitor the two endpoints of a SH-PW . [MPLS OAM] which describes generic OAM procedures for MPLS networks 1.1. Terminology This draft uses the terminology introduced in [L2VPN OAM FWK] and [PWE3 FWK]. In addition the draft introduces the following terms: . Access Network: is defined as a network between the CE and the PE devices that can support access services and ACs. . AS (Access Service): This is a new concept introduced in this document.It is defined as a transport service between the CE and the PE devices over which ACs can be multiplexed. Its role is similar to PSN that provides a transport service for PWs between PEs. . E2E L2 Service: the E2E L2 service provided by the E2E SP and seen by the end customer. . PE SA (PE Service Aware): the PE is aware of the E2E Service and able to process such native service PDUs. . PE NSA (PE Non Service Aware): the PE has no knowledge of the E2E Service. 1.2. General considerations Different types of L2 services requiring the use of PWs are described in [L2VPN-FRWK] and are classified under the following three categories: . VPWS is a point-to-point service where CEs are presented with point- to-point virtual circuits. These point-to-point services can also be sub-classified in two types: homogeneous (End User to SP Network Interfaces are of the same type) and heterogeneous (End User to SP Network Interfaces are of different type). . VPLS is a bridged LAN service provided to a set of CEs that are members of a L2 VPN. CEs that are member of the same service instance communicate with each other as if they are connected via a bridged LAN. . IPLS is a special VPLS which is used to carry only IP service packets. All these services rely on the use of PWs whose architecture is described in [PWE3 Architecture]. The reference model for the network architecture between PEs is presented in Figure 1. Delord, et. al. Expires April 2006 [Page 4] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | native service native service Figure 1: PWE3 Network Reference Model In the most general case the PE is considered to be Service Aware (SA) as the PE has some knowledge of the E2E Service. It can process native service PDUs to implement service specific functions (for example forwarding for VPLS service) and to encapsulate service PDUs onto the PW. In some specific cases it could be envisaged not to process native service PDUs at PE level, for example for point to point service (VPWS service). In that case each PE encapsulates the access technology over the PW to the remote PE, and is considered to be Not Service Aware (NSA). This configuration is particularly relevant when both access networks use the same technology. Depending on the service purchased, the management of the CEs can fall under the responsibility of either the SP or the customer itself. Similarly, Figure 1 shows that the SP uses the PSN to deliver its service but it also needs to rely on two access networks (between CE1 & PE1 and between CE2 & PE2). The emulated service relies then at least on three different networks that can be owned and managed by different entities. Furthermore, the capabilities of every network device (PESA or PENSA) may lead to specific OAM limitations (a network device not being able to process specific OAM flows). For all these reasons that provide a complex problem space, the Access part needs to be accurately taken into account by extending the [PWE3 Architecture] reference model. This document introduces PWE3 OAM framework and requirements. Delord, et. al. Expires April 2006 [Page 5] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 2. Extension to the Architecture Reference Model This section extends the PWE3 architecture reference model by including a detailed model of the access portion of the network. 2.1. PWE3 Architecture Reference Model PWE3 architecture describes the reference model presented in figure 1. In this architecture reference model, end to end service is provided between two CEs located in two remote customer sites. Each CE is connected to a PE using an AC which carries native service data units. At the PE level these native service data units are processed to perform: . Specific functions necessary for service delivery using a Native Service Processing (NSP) component . Selective forwarding of native service data units between ACs and PWs using a Forwarder component. Native service data units are then encapsulated within a PW for transmission over the PSN to the remote PE, where symmetrical operations to those described previously are performed to deliver native service data units to the remote CE. A given PW carries data units associated to only one service. Between PEs, PWs are generally grouped and multiplexed in a PSN Tunnel for transparent transport over the PSN. This requires a PW demultiplexer function as defined in [1] to provide the capacity to deliver multiple PWs within a single PSN tunnel. This includes the definition of a PW identifier that must be unique at least per PSN tunnel. The transport service provided by a PW between two PEs can alter native service characteristics so the PW is assumed to deliver only service emulation between its ingress/egress interfaces. For the core network only the PSN tunnels are visible (PWs are only processed at PE level). PSN tunnels are initiated and terminated at ingress and egress PEs where PWs multiplexing within PSN tunnels is achieved. PSN tunnels are processed within the PSN and provide connectivity between PEs with the appropriate QoS characteristics required by the transported services. 2.2. Framework extension based on the access service and layered model Figure 2 presents the extension of the architecture reference model by taking into account the access network. +----+ +----+ +-----+ | PE1|==========| PE2| +-----+ | | | | | | | | Delord, et. al. Expires April 2006 [Page 6] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 | CE1 | +---+ +---+ | | | | +---+ +---+ | CE2 | | |--|NTU|--|NTU|-| | | |-|NTU|--|NTU|--| | +-----+ +---+ +---+ | |==========| | +---+ +---+ +-----+ +----+ +----+ A<------------------------E2E-Customer-Service---------------------> B1 <-----------------E2E-Service-Provider-Service---------> B2 <--------AC--------><-----PW----------><------AC-------> C <---------> <-----------> <---------> Access Service Transit Service Access Service A: Customer Layer B1: End to End Service sub-layer of the E2E Service Provider Layer B2: Network sub-layer of the E2E Service Provider Layer C: Network Layer FIGURE 2: Layered Model for an E2E SP Today, an AC is defined as the means to attach a CE to a PE, and it is assumed that the native service available at the CE level is also available at the ingress and egress interfaces of the PE. An AC is defined as a physical or logical circuit attaching a CE to a PE [PWE3- ARCH]. It is not explicitly defined as a transport mechanism for native services between a CE and a PE as is the case for a PW between PEs. This simplified view of the access part of the reference model is well adapted for simple configuration, typically for a CE offering only one service (one L2 VPN service) and in addition physically connected to a PE by a point to point link. It is however more difficult to apply this model to more complex configurations (e.g the CE is not directly attached to the PE, or the E2E SP is relying on another SP for the access part). For these configurations it is useful to describe more precisely the access part of the reference model. If we consider the case of a Service Provider (called here E2E SP) offering to customers end to end services with a national or international coverage, the service architecture model applicable to this kind of SP is represented in figure 2. It shows: . customer equipments located at the entrance of each customer site (CPE), . SP equipments located in customer sites (CE) and in his POPs (PE), . the Access Networks (represented as NTU edge equipments) and . Access services used for connection of customers to POPs, . Transit Network and Transit service used for POPs interconnection. Delord, et. al. Expires April 2006 [Page 7] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 Figure 2 also details the different levels of service: . end to end customer service defined between customer equipments . service provided by the E2E SP between the customer interface of CE equipments . AC established between CE and PE and PW between PEs as defined in the IETF reference model. Figure 2 basically shows how the different elements constituting this model can be organized in a layered approach. In this layered model two adjacent layers are expected to have a client/server relationship between them. Each server layer is responsible for all the functionalities it implements to deliver the negotiated service to the client layer: transfer of information, QoS (prioritization, policing, shaping, etc.), signaling, OAM. The main interest of this client/server architecture is the introduction of some form of hierarchy in the global architecture allowing a more precise definition of the expected role of each entity. Another advantage is the limitation of required interworking mechanisms between the different networks, as these mechanisms can be rather complex particularly when the peer networks use technologies based on different approaches (connection oriented versus connectionless oriented). The proposed layering presented in figure 2 is based on three distinct layers: . Customer layer . E2E SP layer . network layer Additional layers could be introduced, particularly at the network layer, but this would increase the complexity of the model with only limited added value for the discussion here. This model clearly shows the difference between an AC and an Access Service. It also shows that if interworking can be envisaged between an AC and a PW, this is not the case between an Access Service and a PW without breaking the layered structure of the model. The detailed description of these layers in presented as an Appendix. 3. PWE3 OAM Framework & Requirements This section introduces PWE3 OAM framework and OAM requirements. This version of the document is attempting to synchronize the PWE3 OAM framework and requirements with the [L2VPN OAM FRMK]. Delord, et. al. Expires April 2006 [Page 8] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 3.1. PWE3 OAM Framework TBD. This will be based on OAM framework constructs in [L2VPN OAM FRMK]. 3.1.1. OAM Domains TBD. As presented in figure 2 an E2E service is generally implemented using several underlying networks, each operated by a separate networks/service provider. Each network is composed of a set of equipments interconnected by physical and/or logical links. It provides services (Access or Transit services for example) and generally implements its own supervision solution for monitoring of these services. If supervision is based on OAM mechanisms this leads to the definition of an OAM domain. As for the service point of view, OAM domains can be organized in a layered model with client/server relationship between layers. From Figure 2 it can be seen that OAM domains can be positioned at the same level in the layered model (adjacent domains) or at different layers (hierarchical domains). 3.1.2. Propagation of information between OAM Domains TBD. This will be based on OAM framework concepts in [L2VPN OAM FRMK]. 3.2. PW OAM Requirements This section of the draft focuses on OAM requirements that are applicable to PWs. The L2VPN service requirements are described in [L2VPN_OAM_FWK]. A fault affecting the network can be treated using a recovery procedure at service level resulting in a short interruption of the services supported by the network, with a rapid return to a normal state of operation. For example a link failure in a MPLS based network can be recovered at service level using a back up LSP. However the fault is still present in the network and the network provider needs additional diagnostic tools to identify and locate the fault in order to start recovery procedure at network layer. Delord, et. al. Expires April 2006 [Page 9] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 3.2.1. Generic Requirements Transfer plane mechanism: a preliminary requirement regarding OAM mechanisms is the fact that they must be based on OAM information carried through the network using the same path as native service data units. OAM messages must be transported using the transfer plane not the control plane. OAM information containment: filtering of OAM information at the edge of an OAM domain (MEP location) must be possible. It must be possible to strictly contain OAM information generated in a given OAM domain inside this domain. This implies filtering of internal OAM information to prevent leaking outside the domain. It also implies filtering of external OAM information to prevent injection inside the domain. It should also be possible to configure filtering of OAM information to allow propagation of some OAM information between domains (e.g. alarm indication). Client/server OAM relation: client/server relationship at the edge of an OAM domain (MEP location) must be possible between hierarchical OAM domains. It must be possible to configure filtering of OAM information to allow propagation of some OAM information between hierarchical domains (for example alarm indication). Inside a single OAM domain client/server relationship must be possible between different layers at MEP location. It must be possible to configure filtering of OAM information to allow propagation of some OAM information between layers (e.g. alarm indication between network and service layers). Transparency to OAM flows: within one OAM domain it must be possible to transport transparently the OAM information related to upper layer domains. E.g. E2E SP service must be able to transport transparently end to end customer service OAM. Identification of OAM traffic: within an OAM domain it must be possible to clearly distinguish OAM traffic flows from other traffic flows without having to process the OAM message. Identification of OAM flows: within an OAM domain it must be possible to clearly identify a given OAM traffic flow and make an unambiguous association with the monitored entity to which this OAM flow applies. It must also be possible to discriminate OAM traffic flows generated inside the domain from OAM traffic flows generated by upper layer domains in order to guarantee transparency. Processing of OAM flows: each device in an OAM domain must be able to determine whether to process a given OAM message locally (MEP/MIP) or pass it through without processing. This must be achieved using information (like an OAM flow identifier, selective addressing of MEP/MIP equipment, etc) located inside the header of OAM messages. The processing for passed thru OAM flows must be the same as for normal traffic flows within all devices. This is particularly true for equipments that are not implementing OAM capabilities. Delord, et. al. Expires April 2006 [Page 10] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 Bidirectional OAM flows: OAM mechanisms must allow bidirectional exchange of OAM information, at least between peer MEPs. This bidirectional information flows is required to allow implementation of some OAM mechanisms, like backward alarm indication propagation, loopback, performance monitoring, etc. Depending on the type of OAM function it is however not always required that the return path uses the same data path through the transfer plane as service data unit OAM activation/deactivation must be harmonized with the set-up/tear-down of the monitored entity. 3.2.2. Specific Requirements This paragraph details specific OAM requirements applicable to PWs. 3.2.2.1. Connectivity Fault Detection & Verification The OAM mechanisms must provide the availability to monitor connectivity between two peer MEPs (for example for the E2E SP from CE to CE). This connectivity verification must be based on OAM information carried through the network using the same path as native service data units (typically OAM CV messages periodically exchanged between MEPs). Connectivity verification must provide the availability to detect a failure of the whole service. Bidirectional connectivity verification is achieved using a CV OAM mechanism in each direction. In case of Loss of Connectivity (LOC) detection at the sink MEP, this MEP must enter a not operational state for the considered Maintenance Entity (for example end to end service). The sink MEP must generate a backward alarm indication to the source MEP of the ME (RDI or BDI, see below). If the Maintenance Entity is a server layer for an upper layer client layer it must also be possible to generate at sink MEP a forward alarm indication to client layer (AIS/FDI see below). Upon reception of the backward alarm indication by the source MEP, the source MEP must not generate a backward alarm indication at client layer (this backward alarm indication will be generated internally to the client layer by the client sink MEP). The principle of operation of alarm indication described here is detailed in the following paragraph. These alarms must be sent periodically until a normal operational state is recovered. In all cases it should be possible to report the type of fault affecting the service (LOC type of alarm or LOC for server layer). It must be possible to use the CV OAM mechanism in continuous mode for proactive monitoring and in an on demand mode for punctual verification. Delord, et. al. Expires April 2006 [Page 11] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 In continuous mode the detection time of this connectivity verification procedure must be configurable to match different types of application, and to be able to provide homogenous treatment over several networks. The detection time required for protection is in the sub-second order. Connectivity verification mechanism should also provide the availability to detect a misbranching or misdirection affecting only a portion of service traffic. In order to improve detection time it could be useful to allow MIPs to analyse CV messages and generate LOC AIS/RDI alarm toward sink MEP. It should be noted that CV mechanism can be used to provide information on network or service topology, as when CV messages have been treated each MEP has knowledge of all its peer MEPs (see below Traceroute function). 3.2.2.2. Connectivity Fault Notification & Alarm Notification Fault Notification is reported using alarm indication messages toward both MEPs in forward direction (to the destination or sink MEP) and in backward direction (to the source MEP). This two types of alarm notification are generally referred as AIS/RDI or FDI/BDI. It is useful to be able to report the type of fault within this alarm indication messages. It must be possible to propagate this alarm indication to adjacent and hierarchical OAM domains. Within a single OAM domain it must be possible to propagate alarm indication between Maintenance Entities located at different layers having client/server relationships. Within an OAM domain it must be possible to coordinate the generation of alarm indications in order to generate only the most appropriate alarms, in order to avoid creation of a storm of alarm indications. It must be possible to generate periodically the alarm indication messages as long as the fault is active. In case of return to normal operational state, the generation of alarm messages must be stopped. This implicitly indicates a return to a normal state of operation, no specific message is required. It must be possible to generate alarm indication in the following cases: . Upon detection of a loss of connectivity (LOC): The use of alarm indication in such case is described in the previous paragraph. . Upon reception of a default indication from a server layer: This is typically a transport failure indication reported by an underlying network layer to the service layer (for example a link failure between two equipments). The use of alarm indication in such case is described below. Delord, et. al. Expires April 2006 [Page 12] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 In case of default indication reported by the server layer the first equipment (MIP/MEP) detecting the default at the service layer ME must generate a forward alarm indication to the sink MEP (AIS/FDI). Upon reception of the alarm indication the sink MEP must enter a not operational state for the considered Maintenance Entity. The sink MEP must generate a backward alarm indication (RDI/BDI) to the source MEP of the ME. If the service Maintenance Entity is also a server layer it must be possible to generate at sink MEP a forward alarm indication to client layer. Upon reception of the backward alarm indication by the service source MEP, this source MEP must not generate a backward alarm indication at client layer (this backward alarm indication will be generated internally to the client layer by the client sink MEP).The same OAM mechanism must be implemented in the other direction to achieved bidirectional default notification. 3.2.2.3. Connectivity Fault Localisation Preliminary note: Regarding Fault Localisation, the tools required by a service provider are not as sophisticated as the ones that are required by a network provider. For example in the service architecture presented in figure 2, the E2E service provider must be able to determine if the fault affecting the E2E service comes from one of the access networks or from the transit network. The precise localisation of the fault inside the network is the responsibility of the relevant network provider. As a consequence the Fault localisation described here is not required from a SP perspective. In case of loss of connectivity or fault notification it must be possible to apply OAM mechanisms to further diagnostic the default: identification of the type of fault (for example a link or equipment failure) and localisation. For connection oriented network this can be achieved directly using some form of loopback mechanism (assuming the data path is already known). Loopback request must be initiated only by the source MEP for each transmission direction. Loopback must be possible at sink MEP (end to end loopback for the ME) and at intermediate MIPs. For MIPs two loopback options are possible: . a selective loopback performed only by a destination MIP identified in the loopback request (by its address or a MIP identifier), . a multiple loopback performed by all MIPs located along the data path. In that case each answer to the loopback request must include a MIP identifier to allow discrimination of answers by the source MEP which originates the loopback request. Delord, et. al. Expires April 2006 [Page 13] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 Non intrusive loopback is typically used in this case if only connectivity is to be checked. For connectionless network a preliminary step is necessary for the identification of the data path followed by the service within the network (some form of Trace Route function). This function can be implemented using a multiple loopback mechanism, however it will hardly provide visibility on network topology (in addition loopback request message will be processed using the control plane inside each equipment instead of the data plane). Additional tools for discovery of network topology are then required for connectionless network, as well as for discovery of service topology (particularly in the case of Ethernet multipoint to multipoint services). Note: The interest of a fault localization function has to be carefully studied for networks using mechanisms for automatic recovery, for example Ethernet based networks using STP protocol (combined with the fact that MAC tables are regularly aged erasing the data path history). 3.2.2.4. Performance Management (PM) Performance management should be possible using OAM information. The main objective of PM is to measure the level of performance of a network or a service in order to verify the correct operation of the network or the compliancy of the service with its negotiated SLA/SLS. Performance Management (PM) mechanism could also be used to provide the capability to avoid congestion on a network or used as a trigger to switching traffic to another PSN tunnel which meets SLA/SLS for example. The basic performance parameters that should be monitored are: . effective bandwidth allocated to the service, . number of lost end to end service data units, . end to end transfer delay for service data units, . Variation of this transfer delay (jitter). Additional parameters can be monitored like enhanced statistics (number of service data units transmitted, received, dropped at maintenance points), service availability, etc. Performance management requires the definition of dedicated OAM information: testing signal to evaluate the error rate, time stamp to evaluate transfer delay, etc. Simplified performance management is possible using: . connectivity verification mechanism (one way transfer delay, estimated error rate) Delord, et. al. Expires April 2006 [Page 14] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 . loopback mechanism (two way or round trip transfer delay estimation). It should be noted that estimation of one way transfer delay assumes the existence of a common clock reference. Although desirable this requirement is less sensitive from an OAM point of view as performance monitoring can be implemented using alternative mechanisms more or less related to Network or Service Management System, for example generating specific test data flows between service end points with some form of statistical analysis or based on collection of general network statistics. This is particularly true for a L2 VPN service used to build an L3 VPN service. Note: This point needs further developments to define precisely the operational state conditions during which PM is applicable, as it is done for MPLS LSP in ITU-T recommendation Y.1711. 4. PWE3 Applications & OAM Scenarios This section describes different options offered to a SP for the E2E service monitoring and their application to the different types of P2P services. The solutions are described here in the E2E SP perspective in the sense that it should always be possible to provide E2E service supervision, whatever the underlying networks implement (or not) in term of supervision solution. 4.1. Service Supervision The first requirement for the E2E SP is the capacity to monitor the end to end services offered to his customers between service UNIs (between CEs), with two main objectives : . verify connectivity end to end, . verify performances level to guarantee SLA (transfer delay, packet loss, etc) When an end to end service is declared in a not operational state the E2E SP must be able to identify which element of the end to end service architecture is affected by a fault. He must be able to unambiguously determine if the correction procedure is under his responsibility or if he must refer to one of the underlying network/service operators. In the case of detection of a fault at E2E service level, the E2E SP must have the possibility to verify separately the status of each AC and the status of the PW. It must also be able to monitor the CE and PE equipments to verify if they work correctly. Delord, et. al. Expires April 2006 [Page 15] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 The verification of AC and PW segments imply some form of connectivity verification mechanism. The monitoring of CEs and PEs can be done using the E2E SP Network Management System. The end customer may also want to monitor his service between his equipments connected to CE, using some specific OAM flows that have to be transported transparently using the E2E SP service. Considering that the Access and Transit services have also to be monitored by their respective network/service providers this leads to an end to end architecture composed of typically four hierarchical OAM domains. The following paragraphs detail several scenarios to satisfy E2E service supervision requirements. These scenarios differ on two aspects: . E2E service supervision, . Segment Supervision 4.1.1. E2E Service Supervision This end to end service supervision can be based on a specific OAM mechanism implemented between CEs, or on OAM information generated by the different elements used to build the end to end service, collected and/or reported to both CEs or directly to the E2E service level. Three scenarios are detailed below. Selection between them depends on various factors like the relative complexity between CE and PE, the type of OAM functions required, the end to end architecture (PE service aware or not, type of Access network, the possibility by legacy equipment to support or not specific OAM functions, the PW encapsulation type, etc). 4.1.1.1. Using Specific End to End OAM Mechanism (option 1) In this scenario a ME is defined from CE to CE associated with specific OAM flows for end to end supervision. This ME is typically defined at E2E SP service level. Each CE is then defined as MEP originating and terminating OAM flows, both PEs can be defined as MIPs if they are service aware, but this is not required. This solution allows end to end supervision of service. Some form of fault localisation is also possible if MIPs are defined at PE level using for example a loopback mechanism. The main advantage of this solution resides in the fact that the OAM solution can be defined independently of other underlying elements of the end to end architecture: availability or heterogeneity of OAM information at AC and PW levels. In addition in its minimal form (without MIP at PE level) only the CEs are involved in service Delord, et. al. Expires April 2006 [Page 16] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 supervision, reducing complexity at PE level as well as potential scalability issues. This solution offers the possibility to build dedicated OAM mechanisms (for example a Connectivity Verification procedure or the definition of a Performance Management strategy) with characteristics directly linked to specific parameters defined in service SLA. The main drawback of this solution is the increase of functionalities needed in the CE that can result from the support of specific OAM mechanisms. This scenario is not applicable to a very simple CE implementing only network termination functions (media converter type). This solution also suffers from the lack of fault localisation capability. If this function is necessary and cannot be implemented using a loopback procedure as described above, additional mechanisms are required for segments supervision. 4.1.1.2. Using Interworking between OAM Segments (option 2) In this scenario a ME is defined for each segment associated with specific OAM flows for segment supervision: . ME is defined for each access part with MEPs at CE and PE . Another ME is defined for transit part with MEPs at both PEs End to end supervision is based on propagation of OAM information between Maintenance Entities (between MEPs). The segment Maintenance Entities can be defined at E2E SP service level if both PEs are service aware, otherwise they should typically be defined at AC and PW levels. Segment supervision is detailed in the following paragraph. If all MEs are defined at service level propagation of OAM information is rather easy as the same technology is used end to end. If MEs are defined at AC and PW levels the OAM flows used by each ME can be based on different technologies and an Interworking function is generally required to map OAM information between MEs. OAM information reported at each CE allows simultaneously supervision of end to end connectivity and fault localisation (if information on localisation of fault could be propagated between MEs) in one direction. At the CE level it is still necessary to generate aggregated information applicable to end to end service. This model is rather in contradiction with the basic OAM principle described above stating that a MEP originates and terminates OAM flows. This model can lead to a rather ambiguous situation where a ME may have to carry alarm notifications that apply to other MEs (possibly not Delord, et. al. Expires April 2006 [Page 17] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 adjacent MEs). This also implies in most cases an extension of existing alarm notification messages to be able to discriminate alarm notification applicable to the local ME from those affecting other MEs. For example an AIS/FDI message carried over an AC must be able to indicate if the reported fault affects the local AC, the PW or the remote AC. Though this interworking model seems hardly applicable for OAM domains managed by separate operators, for example in the case of Access and Transit networks, it may however be envisaged here if all MEs are part of one or several OAM domain(s) managed by the same E2E SP. The main advantage of this solution resides in the fact that both end to end and segments supervision is implemented using only one layer of MEs. As a consequence no specific OAM mechanisms are necessary at the CE level for end to end supervision. This solution has no real drawbacks if segment MEs are defined at service level, except the fact that it is not fully in line with the principle of OAM modelling. In that case interworking is reduced to simple adaptation of OAM information using the same service technology (for example in the case of a L2 VPN service if CE and PE implement Ethernet bridge functions). In the case where MEs are defined at AC and PW levels, this solution is first conditioned by the fact that OAM mechanisms must be available at AC and PW levels. This point is mitigated by the fact that both AC and PW are implemented by the E2E SP who could add the necessary missing blocks (ideally based on the same OAM mechanisms to ease interworking). It has however one main drawback: the PE will need to implement mapping function resulting from the introduction of the Interworking function. This is particularly true when AC and PW are based on different technologies, particularly if it is necessary to map OAM information between connection oriented and connectionless oriented technologies. This case is obviously realistic as it corresponds to an Ethernet AC mapped to a MPLS PW. 4.1.1.3. Using Client / Server relation (option 3) In this scenario a ME is defined for each segment associated with specific OAM flows for segment supervision: . ME is defined for each access part with MEPs at CE and PE, . Another ME is defined for transit part with MEPs at both PEs. An additional ME is defined between CEs (each CE is a MEP) for end to end supervision. In this scenario PEs must be service aware so both PEs can be defined as MIPs, but this is not required. Client/server model is Delord, et. al. Expires April 2006 [Page 18] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 used for propagation of OAM information between segment MEs (server) and end to end ME (client). Like in the previous scenario the segment MEs can be defined at E2E SP service level (as both PEs are service aware), they could also be defined at AC and PW levels. Segment supervision is detailed in the following paragraph. If all MEs are defined at service level, propagation of OAM information between server and client layer is rather easy as the same technology is used. If segment MEs are defined at AC and PW levels, the OAM flows used by each ME can be based on different technologies, and an adaptation function is generally required to build OAM messages appropriate to the client layer. OAM information reported by the server layers to the client layer is composed of forward fault notification (AIS/FDI). It simultaneously allows monitoring of E2E service connectivity and fault localisation between segments. Compared to the first scenario, the end to end ME does not require the implementation of a connectivity verification mechanism. It only requires implementation of fault notification processing. Compared to option 2 this model is fully in line with the principle that MEPs originate and terminate OAM flows and can propagate OAM information to the client layer. With this solution, end to end supervision is mainly built using segments supervision which results in very limited OAM mechanisms needed at CE level (specific functions are however required for AC supervision)requiring the implementing of propagation functions. This model has no real drawback, except that it can only be used if PEs are service aware in order to be able to generate alarm notification at E2E service level. 4.1.2. Segment Supervision The supervision of a segment can be implemented using mainly three different options, already partially described in the previous paragraph. In all scenarios a ME is defined for each segment, associated with specific OAM flows for segment supervision: . ME is defined for each Access part with MEPs at CE and PE . ME is defined for Transit part with MEPs at both PEs The differences between the various options are detailed below. If performance monitoring is important at E2E service level, segment monitoring is mainly focused on connectivity verification only (with fault localisation treated at the underlying network level). Delord, et. al. Expires April 2006 [Page 19] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 4.1.2.1. MEs at Service Level In this scenario MEs are defined at service level and mapped over the segments, independently of underlying ACs and PW. This scenario is only applicable if both PEs are service aware in order to be able to generate and terminate OAM flows at service level. The main advantage of this scenario resides in the fact that segment supervision is independent of the underlying ACs and PW, and that the same OAM mechanisms can be used for all segments, directly linked to E2E service (supervision parameters can be fine tuned depending on service SLA). It also facilitates end to end supervision based on interworking or on client/server model. In addition to the restriction to service aware PEs this scenario requires specific functions at CE and PE levels, and may duplicate existing mechanisms already available at AC and PW levels (for example VCCV for PW). Note: This is typically what is currently done in IP-VPN to monitor the access part between the CE and the PE, an ICMP Ping message is generated from the PE to the CE to check their connectivity. 4.1.2.2. Specific OAM solution for supervision of each segment In this scenario MEs are defined at ACs and PW levels (independently of transported E2E service, even if alarm propagation to service level is possible). As ACs and PW generally use different technologies, different OAM mechanisms have to be used for ACs and PW supervision. The main advantage of this scenario resides in the fact that it is applicable in all cases even if PEs are not service aware. It can reuse existing mechanisms available for ACs and PW supervision (for example VCCV for PW). This solution is also independent of underlying Access and Transit services and can use specific supervision parameters (common to both AC and PW) depending on transported services and related SLA (like the previous one). It however has less relation with E2E service resulting in a more complex implementation of the client /server model for end to end supervision. It also requires specific OAM mechanisms at CE and PE levels. 4.1.2.3. Client/Server model with underlying network services In this scenario the supervision mechanisms available at the underlying Access and Transit services (server layers) are used with propagation of OAM information to the client ACs or PW (client layers). This scenario Delord, et. al. Expires April 2006 [Page 20] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 is of course conditioned by the existence of such mechanisms at Access and Transit levels. The main advantage of this scenario resides in the fact that no specific OAM mechanisms are required for segments supervision, resulting in a simplification of CEs and PEs. On the other hand, as an Access or a Transit service generally transports several services (particularly a Transit service), monitoring of the segment may not be finely tuned to meet the E2E service supervision requirements. 4.2. Application to network scenarios This part of the document focuses on examples of Point to Point services (either homogeneous or heterogeneous) describing how the MEs are defined and where the MEPs and MIPs are located depending on the chosen monitoring option. 4.2.1. Homogenous Services A service is considered to be homogenous when the two Customer interfaces at CE1 and CE2 are of the same type. In this case, there are two alternatives that are explained in the following paragraphs. The first one is to have a PE that is Service Aware (SA). This means that the PW encapsulation type is of the same type as the E2E service (ACs are terminated/originated at the ingress/egress of each PE and the PW encapsulates native service PDUs). In the second case where the PW Encapsulation type is different from the E2E service, the PE is Non Service Aware (NSA) which implies that the PE does not have any knowledge of the E2E emulated service. This configuration could be considered for P2P services where no native service PDUs processing is required at PE level. For example, considering an Ethernet over ATM encapsulation (RFC2684 B) is performed at CE1 to transport an E2E Ethernet service over an ATM access network. If the PW is of Ethernet type, then PE1 needs to de- encapsulates Ethernet from ATM and encapsulates directly Ethernet over the PW. If the PW is of ATM type then the PE only processes ATM cells, and has no idea that in fact the E2E service is Ethernet based. 4.2.1.1. PE Service Aware (PE SA) Figure 3 shows for the case of service aware PEs, how the MEs are defined and where the MEPs and MIPs are located for the different layers of the model considering the three options presented in this document. Delord, et. al. Expires April 2006 [Page 21] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 +----+ +----+ +-----+ | PE1|===============| PE2| +-----+ | |------|............PW1..........|--------| | | CE1 | | | | | | CE2 | | |------|............PW2..........|--------| | +-----+ | |===============| | +-----+ +----+ +----+ opt1| A MEP---MIP-----------------------------------------MIP-----MEP | ^ ^ | | | | B1 MEP--------MIP------------------MIP---------MEP opt2| A MEP---MIP-----------------------------------------MIP-----MEP | ^ ^ | | | |B1 or B2 MEP-----MEP<->MEP-------------MEP<->MEP-----MEP opt3| A MEP---MIP-----------------------------------------MIP-----MEP | ^ ^ | | | | B1 MEP-------MIP---------------------MIP-------MEP | ^ ^ ^ ^ ^ ^ | | | | | | | | B2 MEP----MEP MEP-----------------MEP MEP------MEP A is the E2E Customer Layer B1 is the E2E Service Provider layer B2 is the AC/PW/AC Layer FIGURE 3: MEs definition and MEPs and MIPs location for PE SA As PE is service aware it is possible to define a MEP/MIP at E2E service level for both PEs, for the three options. The MIP at CE level for E2E customer service is optional as this layer could be completely transparent for the CE (for example a L3 service implemented between CPEs over a E2E L2 service provided by the SP between the CE interfaces). . Option 1 is based on end to end supervision between CEs . Option 2 is based on segments supervision plus interworking. OAM handling for this scenario is described in OAM-Message Mapping & VPWS interworking . Option 3 is based on client/server model. In this scenario the errors can happen at any of the following location: AC, PW, AS, PSN Tunnel or PE itself Delord, et. al. Expires April 2006 [Page 22] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 For all scenarios, the propagation of an alarm will reach the first MEP that will terminate this error by entering the relevant error state, by sending a backward alarm indication towards its peer MEP. Depending on the option chosen the MEPs will also generate an alarm on the upper layer if they are MIPs or MEPs of this higher layer (option 3), otherwise they will have to pass the information along (option 2). For example if we take option 2 and 3, for an error happening on an AC, in option 2, the PE will receive an alarm at the AC level, as it is not a MIP of the higher layer (which is the E2E SP layer) it will have to pass it over to the next MEP of the same level (for example map it onto a VCCV alarm or an LDP Status message). Considering option 3, if the same error occurs in the AC, the alarm will be terminated for that level at the PE and propagated at the upper layer (E2E SP layer). 4.2.1.2. PE Non Service Aware (PE NSA) As explained above, PE NSA can happen when the PW type is different from the E2E service. However, in such a situation, it is possible to see the CE as two logical devices in one. One part of the CE does the mapping between the E2E service and the technology that will be carried over the PW (for example the RFC 2684B). The second part acts as if the E2E service was the one carried onto the PW (referred in figure 4 as B1 bis level). Therefore, even if the PE is NSA at B1 level it could be considered as service aware at B1 bis level. One can then fall back into the previous category, which means that both IW and client/server models are still applicable. Figure 4 shows in the case of non service aware PEs how the MEs are defined and where the MEPs and MIPs are located for the different layers of the model including the two logical devices in the CE and considering the three options presented in this document. Delord, et. al. Expires April 2006 [Page 23] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 +----+ +----+ +-----+ | PE1|===============| PE2| +-----+ | |------|............PW1..........|--------| | | CE1 | | | | | | CE2 | | |------|............PW2..........|--------| | +-----+ | |===============| | +-----+ +----+ +----+ opt1| A MEP---MIP-----------------------------------------MIP-----MEP | ^ ^ | | | | B1 MEP--------MIP------------------MIP---------MEP (or B1 bis) opt2| A MEP---MIP-----------------------------------------MIP-----MEP | ^ ^ | | | | B2 MEP-----MEP<->MEP-------------MEP<->MEP-----MEP (or B1 bis) opt3| A MEP---MIP-----------------------------------------MIP-----MEP | ^ ^ | | | | B1(bis) MEP-------MIP---------------------MIP-------MEP | ^ ^ ^ ^ ^ ^ | | | | | | | | B2 MEP----MEP MEP-----------------MEP MEP------MEP A is the E2E Customer Layer B1 is the E2E Service Provider Layer for the Native Service B1(bis) is the E2E Service Provider layer for the Non Native Service B2 is the AC/PW/AC Layer FIGURE 4: MEs definition and MEPs and MIPs location for PE NSA As PE is not service aware it is not possible to define a MEP/MIP at E2E service level for both PEs, for the three options. This is however possible for B1 bis level. The MIP at CE level for E2E customer service is optional as this layer could be completely transparent for the CE (for example a L3 service implemented between CPEs over a E2E L2 service provided by the SP between the CE interfaces). Delord, et. al. Expires April 2006 [Page 24] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 4.2.1.3. Conclusion for Homogenous Services The choice for one option over the others is basically under the SP responsibility. It is important to point out though that the use of the client/server method (option 3) provides some advantages over the other two (in terms of transparency for example). However, if for some reason this solution is not applicable, then option 1 or option 2 should be used depending on global architecture, possibility of legacy equipments, etc... 4.2.2. Heterogeneous Services A service is considered to be heterogeneous when the two customer interfaces at CE1 and CE2 are of a different type (Ethernet on one side and ATM on the other one for example). Of course, some sort of service interworking must take place here. There are two ways of doing it, depending on where the IW function is located. In both configurations, option 1 based on end to end supervision at service level does not seem relevant as the service is not homogenous end to end. If the IWF takes place in one of the PEs (either PE1 or PE2), this is called a Single Sided IW, then a service interworking can be achieved. For example if we want to connect two sites, one in Ethernet and the other one in ATM, one of the PE can do some sort of technology interworking directly between Ethernet and ATM (similar to FRF.8.1 for a mapping between FR and ATM). If SSI takes place, then it is possible to reuse option 3 for the E2E monitoring. Option 2 based on interworking is also applicable at E2E service level or at AC/PW/AC level. If the IWF takes place in both PEs (PE1 & PE2), this is called Double Sided IW (and is defined in the draft [ARP-MEDIATION]) that uses IP Pseudowires, then no real service interworking can be done and therefore, only network IW can occur (between both ACs and the PW). If DSI takes place, then option 3 is not feasible any more since there is no possibility to map an L2 alarm onto an IP alarm. Therefore, option 2 at AC/PW/AC level is the only one applicable in this scenario. Figure 5 shows how the MEs can be defined for heterogenous scenarios and where the MEPs and MIPs are located for the different layers of the model considering the three options presented in this document. Delord, et. al. Expires April 2006 [Page 25] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 +----+ +----+ +-----+ | PE1|===============| PE2| +-----+ | |------|............PW1..........|--------| | | CE1 | | | | | | CE2 | | |------|............PW2..........|--------| | +-----+ | |===============| | +-----+ +----+ +----+ opt2 |A MEP---MIP--------*---------------------*----------MIP-----MEP +DSI | ^ ^ | | | |B2 MEP----MEP<*>MEP-------------MEP<*>MEP------MEP opt2 |A MEP---MIP------------------------------*----------MIP-----MEP +SSI | ^ ^ | | | |B1 or B2 MEP---MEP<->MEP-------------MEP<*>MEP------MEP opt3 |A MEP---MIP------------------------------*----------MIP-----MEP +SSI | ^ ^ | | | |B1 MEP-------MIP-------------------MIP*--------MEP | ^ ^ ^ ^ ^ ^ | | | | | | | |B2 MEP-----MEP MEP---------------MEP MEP-------MEP A is the E2E Customer Layer B1 is the E2E Service Provider layer B2 is the AC/PW/AC Layer * represents an interworking function (either L2 to L2 either L2 to IP PW in the case of the DSI scenario) FIGURE 5: MEs definition and MEPs and MIPs location for layered model 4.2.2.1. Conclusion for Heterogeneous Services The choice for SSI or DSI is basically the responsibility of the SP depending on the same parameters as usual. However it is important to notice that only the SSI scenario allows for service interworking whereas the DSI will always require network interworking. 5. Acknowledgments Delord, et. al. Expires April 2006 [Page 26] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 TBD 6. Security Considerations Security issues resulting from this draft will be discussed in greater depth at a later point. 7. Normative References [L2VPN-OAM-FRW] draft-ietf-l2vpn-oam-req-frmk-04.txt 8. Informative References [L2VPN-OAM-FRW] draft-ietf-l2vpn-oam-req-frmk-04.txt [WILLIS] draft-willis-pwe3-requirements-00.txt [OAM-MSG] draft-ietf-pwe3-oam-msg-map-01.txt [VCCV] draft-ietf-pwe3-vccv-04.txt [PWE3-CNTL] draft-ietf-pwe3-control-protocol-06.txt [LDP-PROV] draft-ietf-l2vpn-signaling-01.txt [VPWS-IW-OAM] draft-aissaoui-l2vpn-vpws-iw-oam-00.txt [MH-PW Req] "Requirements for inter domain Pseudo-Wires",draft-martini- pwe3-mh-pw-requirements-01.txt (Work in Progress) [L2VPN FWK] "Framework for Layer 2 Virtual Private Networks (L2VPNs)",draft-ietf-l2vpn-l2-framework-05.txt (Work in Progress) 9. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Delord, et. al. Expires April 2006 [Page 27] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 10. Authors' Addresses Simon Delord Uecomm 658 Church St Richmond, VIC, 3121, Australia Email: sdelord@uecomm.com.au Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France Email: philippe.niger@francetelecom.com Yuichi Ikejiri NTT Communications 1-6 Uchisaiwai-cho 1-chome Chiyoda-ku, Tokyo 100-8019 Japan Email: y.ikejiri@ntt.com Yuichiro Wada NTT Communications Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, JAPAN Email: yuichiro.wada@ntt.com Deborah Brungard ATT 200S. Laurel Ave. Middletown, NJ 07748 Email:dbrungard@att.com Lei Zhu Sprint 6220 Sprint Parkway Overland Park, Kansas 66251 Email: lei.zhu@mail.sprint.com Alain Vedrenne Equant Heraklion, 1041 route des Dolines, BP347 06906 Sophia Antipolis Cedex, France Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Delord, et. al. Expires April 2006 [Page 28] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 Tokyo 102-8460, JAPAN E-mail: ke-kumaki@kddi.com Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON K2H8E9 Email: mohand@nortel.com Vasile Radoaca Consultant Email : radoaca@hotmail.com Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com 11. APPENDIXES 11.1. Detailed description of each layer of the model 11.1.1. Network Layer In the general case this layer is composed of a set of homogenous and independent networks, each operated by a separate network operator. The different networks are completely independent with client/server relations with the E2E SP layer, and do not require relations between them. Each network implements its own mechanisms necessary for the correct operation of the network and for the support of the offered Access/Transit services (data forwarding, signalling, QoS, OAM, etc). In the considered architecture there are: . two Access Providers offering Access Services to deliver connectivity through Access Networks for connection of CEs to PEs (one Access Network for each POP in figure 2) . one Transit Provider offering Transit Service to deliver connectivity through the PSN for interconnection of PEs. The Transit Service is equivalent to the PSN tunnel defined in the IETF reference model. 11.1.2. E2E SP Layer This layer is composed of the two sub-layers e.g. A network sub-layer that encompasses all the functionalities specifically implemented to support the end to end service offered by the SP to his customers: . AC between CE and PE, . PW between PEs, Delord, et. al. Expires April 2006 [Page 29] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 . Adaptation functions at CE level, . Interworking functions at PE level. These functionalities are implemented only in SP equipments (CEs and PEs). If these functions can be conditioned by the underlying network layers, they are transparent to these underlying network layers. They also provide some form of homogenous server layer for the support on E2E SP service, independently of the underlying network layers. As indicated in the IETF reference model a PW is only processed at PE level and is transported transparently through the PSN using a PSN tunnel. In the same manner an AC is processed only at CE and PE level and is transported transparently through the Access Network using an Access Service. From figure 2 it can be seen that the AS provides connectivity through the Access network as the PSN tunnel does through the Core network. An AC is implemented between the CE and the PE and uses the connectivity provided by an Access Service in a similar manner as a PW does between two PEs using a PSN Tunnel. In others words an AC provides some form of service emulation through the Access network. Based on this analogy between AC and PW a clarification of the AC functionalities can be proposed: . an AC provides an encapsulation mechanism for the transport of E2E SP service data units over the Access Service, . an AC provides a multiplexing mechanism to allow several E2E SP services to share the same Access Service, in addition an AC can provide additional functions for AC management: signalling for establishment/tear down, OAM for supervision of emulated service, etc. This definition could be adapted to a specific configuration. For example, if the E2E SP service and the Access service are compatible (use the same technology) the encapsulation function may not be necessary or if the Access service is used to transport only a single E2E SP service the multiplexing function is not required. Adaptation functions at CE level may be required to allow transport of E2E SP service data units over the Access Network (for example using encapsulation mechanism). Interworking functions at PE level may be required to map information between AC and PW (for example OAM information). These interworking functions can imply interworking between different technologies used for AC and PW (e.g mapping an ATM AIS into a VCCV alarm using BFD). . The end to end SP service: this is the end to end service offered by the SP to his customers, providing connectivity from CE to CE. This service is implemented using the generic functionalities offered by the network sub-layer (connectivity, QoS, OAM, etc), eventually Delord, et. al. Expires April 2006 [Page 30] Internet Draft draft-delord-pwe3-oam-&-applications-02.txt Oct 2005 complemented with additional functions specific to the service. These functions are based on processing of E2E SP service data units, for example frame replication for VPLS service. 11.1.3. Customer Layer This layer is composed of the customer end to end service. In general this service should be transported transparently using the connectivity delivered by the end to end SP service (data PDU, signalling and OAM messages, etc). 12. IPR Notice The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.