Pseudo-Wire Edge-to-Edge (PWE3) Working Group Simon Delord Philippe Niger France Telecom Yuichi Ikejiri Yuichiro Wada NTT Communications Deborah Brungard ATT Alain Vedrenne Equant Lei Zhu Sprint Kenji Kumaki KDDI Corporation Vasile Radoaca Consultant Dinesh Mohan Nortel Ali Sajassi Cisco Systems Internet Draft Document: draft-delord-pwe3-oam-&-applications- May 2005 01.txt Expires November 2005 PWE3 Applications & OAM Scenarios draft-delord-pwe3-oam-applications-01.txt Expires November 2005 [Page 1] Internet Draft PWE3 Applications & OAM Scenarios May 2005 1. 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. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the Pseudowire Emulation Edge to Edge (PWE3) working group at pwe3@ietf.org. 2. Abstract This document provides requirements and a framework for PWE3 Operation Administration and Maintenance (OAM).It extends the PWE3 architecture reference model by including a detailed model of the access portion of the network. This document targets to provide clarification and applicability guidelines for the on going OAM work by describing different implementation solutions and detailing the Pros and Cons of each solution (section 7). Table of Contents 1. Status of this Memo.........................................2 2. Abstract....................................................2 3. Conventions used in this document...........................3 4. Overview....................................................3 4.1. Terminology.................................................4 4.2. General considerations......................................5 5. Extension to the Architecture Reference Model...............6 5.1. PWE3 Architecture Reference Model...........................6 5.2. Framework extension based on the access service and Expires November 2005 [Page 2] Internet Draft PWE3 Applications & OAM Scenarios May 2005 layered model.............................................7 6. PWE3 OAM Framework & Requirements...........................9 6.1. PWE3 OAM Framework..........................................9 6.1.1. OAM Domains................................................10 6.1.2. Propagation of information between OAM Domains.............10 6.1.3. Example of mapping between the OAM FWK concepts and the current building blocks in PWE3 (VCCV, BFD, LSPPING, OAM Message Mapping)...........................................12 6.2. PW OAM Requirements........................................12 6.2.1. Generic Requirements.......................................12 6.2.2. Specific Requirements......................................13 7. PWE3 Applications & OAM Scenarios..........................17 7.1. Service Supervision........................................18 7.1.1. E2E Service Supervision....................................18 7.1.2. Segment Supervision........................................22 7.2. Application to network scenarios...........................23 7.2.1. Homogenous Services........................................23 7.2.2. Heterogenous Services......................................27 8. Acknowledgments............................................28 9. Security Considerations....................................29 10. References.................................................29 11. Author's Addresses.........................................29 12. APPENDIXES.................................................30 12.1. Detailed description of each layer of the model............31 12.1.1. Network Layer..............................................31 12.1.2. E2E SP Layer...............................................31 12.1.3. Customer Layer.............................................32 13. Intellectual Property Statement............................32 3. 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. UPDATE: Some of the requirements for VPLS went to the VPLS OAM Draft and those concerning MH-PW to the MH-PW Reqts. This draft focusses on PWs requirements OAM & framework OAM. 4. Overview The purpose of this document are the following: -extends the PWE3 architecture reference model by including a detailed model of the access portion of the network (section 5) Expires November 2005 [Page 3] Internet Draft PWE3 Applications & OAM Scenarios May 2005 -provides additional requirements as well as a framework for PWE3 Operation Administration and Maintenance (OAM) (section 6) -to provide applicability guidelines for the on going OAM work by describing different implementation solutions (section 7). - to be a baseline for a set of documents that are referenced hereafter. The following documents were taken in consideration for the background of this work: - [MH-PW Req] The OAM requirements for MH-PWs are described in [MH-PW Req] draft and the OAM requirements and framework for L2Services are described in the [L2VPN OAM FWK] draft. - [OAM Message Mapping]specifies the mapping of defect states between a Pseudo Wire 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 Pseudo Wire and the Attachment Circuits (AC) of the end-to-end emulated service for an heterogeneous service - [L2VPN OAM FWK] provides framework and requirements for L2VPN services Additional documents that are related to this work are the following: - [VCCV] which describes how to monitor the two endpoints of a SH-PW - [MPLS OAM] which describes generic OAM procedures for MPLS networks This document contains the following sections: -section 5 extension of the reference model for new types of services -section 6 new OAM reference model -section 7 OAM Scenarios using the reference model 4.1. Terminology -AC (Attachment Circuit): provides service emulation between the CE and the PE (encapsulates & multiplexes native service PDUs over the access service). -Access Network: is defined as a network between the CE and the PE devices that can support access services and attachment circuits. -AIS: Alarm Indication Signal -AS (Access Service): This is a new concept introduced in this document(section 5.2).It is defined as a transport service between the CE and the PE devices over which Attachment Circuits can be multiplexed. Its role is similar to the PSN that provides a transport service for the PWs between the two PEs. -CV: Connectivity Verification -E2E L2 Service: the E2E L2 service provided by the E2E SP and seen by the end customer. -OAM Layer:the services and the network are mapped into layers organized into client/server relationship. Expires November 2005 [Page 4] Internet Draft PWE3 Applications & OAM Scenarios May 2005 -OAM Domain:decomposes a specific layer into domains that can be managed as standalone. -ME (Maintenance Entity): an entity defined in a given OAM domain and associated to a monitored entity for processing of dedicated OAM flows. -MEP (Maintenance entity End Point): is responsible for origination and termination of OAM messages for a given Maintenance Entity. -MIP(Maintenance Intermediate Point):is located between peer MEPs and can processes OAM messages but never initiates or terminates them. -PM: Performance Management -PW (Pseudo Wire): Provides service emulation between the PEs (encapsulates & multiplexes native service PDUs from the AC over the PSN). -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. -RDI: Remote Defect Indicator -SLA: Service Level Agreement -STP: Spanning-Tree Protocol 4.2. General considerations The different types of L2 services requiring the use of PWs are described in [L2VPN-FRWK] and are classified under the three following categories: VPWS, VPLS and IPLS services. 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 (the two End User to SP Network Interfaces are of the same type) and heterogeneous (the two End User to SP Network Interfaces are of different types). VPLS is a bridged LAN service provided to a set of CEs that are members of a 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 the two PEs is presented in Figure 1. |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | Expires November 2005 [Page 5] Internet Draft PWE3 Applications & OAM Scenarios May 2005 +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | 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 responsability 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 (section 5). Following the same reasons we are looking to introduce a new OAM framework and requirements (section 6). 5. 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. 5.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 Customer Edge equipments (CE) located in two remote customer sites. Each CE is connected to a Provider Edge equipment (PE) using an Attachment Circuit (AC) which carries native service data units. An AC is defined as a physical or logical circuit Expires November 2005 [Page 6] Internet Draft PWE3 Applications & OAM Scenarios May 2005 attaching a CE to a PE. 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 two 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. 5.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| +-----+ | | | | | | | | | CE1 | +---+ +---+ | | | | +---+ +---+ | CE2 | | |--|NTU|--|NTU|-| | | |-|NTU|--|NTU|--| | +-----+ +---+ +---+ | |==========| | +---+ +---+ +-----+ +----+ +----+ A<------------------------E2E-Customer-Service---------------------> B1 <-----------------E2E-Service-Provider-Service---------> B2 <--------AC--------><-----PW----------><------AC-------> C <---------> <-----------> <---------> Expires November 2005 [Page 7] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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 two 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: -the customer's equipments located at the entrance of each customer's site (CPE), -the SP's equipments located in customer's 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, -the Transit Network and Transit service used for POPs interconnection. Figure 2 also details the different levels of service: -the end to end customer service defined between customer equipments -the service provided by the E2E SP between the customer interface of CE equipments -the AC established between CE and PE and PW between PEs as defined in the IETF reference model. Expires November 2005 [Page 8] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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 (priorisation, policing, shaping€),signalling, 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: - network layer - E2E SP layer - Customer 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. 6. PWE3 OAM Framework & Requirements This section introduces the OAM framework, based on OAM domains and OAM flows and also introduces additional OAM requirements to support this framework. 6.1. PWE3 OAM Framework Based on the work which is defined in the IEEE 802.1ag, we are extending the notion of OAM Domain, ME, MEPs and MIPs to the PWE3 and L2VPN WGs. These concepts are used as a building block for the PWE3 OAM framework. Expires November 2005 [Page 9] Internet Draft PWE3 Applications & OAM Scenarios May 2005 The following section will present the concepts and at the end of this section we present an example of mapping between this concept and the different building blocks which are defined in PWE3 ([VCCV], [BFD] and [OAM Message Mapping]). 6.1.1. OAM Domains 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). Within an OAM domain an OAM flow is associated with a Maintenance Entity (ME). An OAM flow is defined between one or more source and sink points (point to point or multipoint to multipoint OAM flow), where OAM messages are initiated and terminated. These points are defined as Maintenance entity End Point, MEP. The OAM messages can be processed by intermediate points located between peer MEPs (defined as Maintenance entity Intermediate Point, MIP) but generally not initiated or terminated. Within a single OAM domain it is possible to define OAM flows associated to MEs hierarchically organized, with client / server relation between them. For example a ME can be defined for end to end service supervision where MEPs coincide with service termination points (CEs), and additional MEs can be defined for the supervision of the different segments (Access segment, Transit segment). As the services provided by a network are generally terminated at the interface of the network (defining termination point or end point), their associated OAM flows are also terminated at the edge of the network. The decision on filtering / propagation of OAM information outside a given domain (for example fault alarm indication) must be made at these termination points. Generically, L2VPNs can be viewed as consisting of customer OAM domain, service provider OAM domain, and network operator OAM domain as depicted in Figure 2. 6.1.2. Propagation of information between OAM Domains Expires November 2005 [Page 10] Internet Draft PWE3 Applications & OAM Scenarios May 2005 This section focuses on propagation of information between OAM domains. Two models for propagation are possible: Adjacent domains (new concept): In the most general case adjacent OAM domains are completely independent (for example Access domain and Transist domain), and do not need to have any relationship. As a consequence it is generally not useful or even not desirable to propagate OAM information used in one domain to adjacent domains, so it must possible to contain OAM information used in a given domain to only this domain. However under certain circumstances it may be possible to propagate OAM information between adjacent domains. In that case OAM information is propagated between two adjacent OAM domains positioned at the same level in the layered model (for example Access domain and Transit domain). This model is only applicable when both domains have contractual relationships (existence of a SLA/SLS). In any case this propagation of OAM information must be configurable, generally based on configuration information derived from the SLA/SLS negotiated between network/service providers. This propagation model may also require an interworking function if the OAM mechanisms used in both domains are based on different technologies. This model has one major drawback as it requires for a given OAM domain, the propagation of OAM information relevant to the adjacent domain (for example alarm indication for a default affecting the adjacent domain). Hierarchical domains: As explained above, hierarchical OAM domains can have a client/server relationship: - Transparency Each domain must transport transparently the OAM flows of upper layer OAM domains: OAM flows at level i+1 (or higher) must be transported transparently at level i. - Client / server relation An OAM domain of level i can act as a server level to a client OAM domain of level i+1 providing some facilities for supervision of services at level i+1. For example OAM domain at level i can provide some OAM information on a fault affecting the transport service at level i that can have an impact on transported services at level i+1. In this case OAM information is propagated between a server OAM domain toward a client OAM domain. It must be implemented at termination point only (MEP), and must be configurable. This model is always applicable as the client domain has always contractual relationship with the server domain, at least from the service point of view. This model is also more appropriate as the OAM information (for example alarm indications) is propagated to the client layer that is in fact affected by the fault. In addition this model generally does not require any interworking function between different OAM approaches (this behaviour is similar to what is described in [OAM-MESSAGE-MAPPING] in section 9.5.1). Expires November 2005 [Page 11] Internet Draft PWE3 Applications & OAM Scenarios May 2005 6.1.3. Example of mapping between the OAM FWK concepts and the current building blocks in PWE3 (VCCV, BFD, LSPPING, OAM MEssage Mapping) To be done. 6.2. PW OAM Requirements This section of the draft focusses on OAM requirements that are applicable to PWs. The 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. 6.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 (for example 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 (for example 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 Expires November 2005 [Page 12] Internet Draft PWE3 Applications & OAM Scenarios May 2005 domains. For example the 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: within each device of the OAM domain it must be possible to determine if a given OAM message must be processed locally (MEP/MIP) or must be passed thru, without having to be processed. 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. 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. 6.2.2. Specific Requirements This paragraph details specific OAM requirements applicable to PWs. 6.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 Expires November 2005 [Page 13] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. 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). 6.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. Expires November 2005 [Page 14] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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 form 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. 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. 6.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 Expires November 2005 [Page 15] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. 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). 6.2.2.4. Performance Management (PM) Expires November 2005 [Page 16] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. However simplified performance management is possible using the connectivity verification mechanism (one way transfer delay, estimated error rate), and the 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. 7. PWE3 Applications & OAM Scenarios In the previous paragraph we developed the Framework. Following this we are trying to provide some implementation scenarios to show that this framework applies to PWs. This section describes first the different options offered to a SP for the E2E service monitoring then their application to the different types of P2P services. This first paragraph summarizes the Expires November 2005 [Page 17] Internet Draft PWE3 Applications & OAM Scenarios May 2005 three different ways service monitoring can be performed and details their Pros and Cons. The second paragraph presents application of these three options to homogeneous and heterogeneous 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. 7.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. 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. 7.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 Expires November 2005 [Page 18] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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 differentiated 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). 7.1.1.1. Using Specific End to End OAM Mechanism (option 1) In this scenario a Maintenance Entity is defined from CE to CE associated with specific OAM flows for end to end supervision. This Maintenance Entity 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 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. 7.1.1.2. Using Interworking between OAM Segments (option 2) In this scenario a Maintenance Entity is defined for each segment associated with specific OAM flows for segment supervision : - a 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). Expires November 2005 [Page 19] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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 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 Expires November 2005 [Page 20] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. 7.1.1.3. Using Client / Server relation (option 3) In this scenario a Maintenance Entity is defined for each segment associated with specific OAM flows for segment supervision: - a 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 used for propagation of OAM information between segment MEs (server) and end to end ME (client). Like in the previous scenario the segment Maintenance Entities 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. Expires November 2005 [Page 21] Internet Draft PWE3 Applications & OAM Scenarios May 2005 7.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 Maintenance Entity is defined for each segment, associated with specific OAM flows for segment supervision: - a ME is defined for each Access part with MEPs at CE and PE, - a 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). 7.1.2.1. Maintenance Entities 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. 7.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 Expires November 2005 [Page 22] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. 7.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 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. 7.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. 7.2.1. Homogenous Services A service is considered to be homogenous when the two Customer's 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 Expires November 2005 [Page 23] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. 7.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 section 8.1.1. +----+ +----+ +-----+ | 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. Expires November 2005 [Page 24] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. 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). 7.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 section 8.1.1. +----+ +----+ +-----+ | PE1|===============| PE2| +-----+ Expires November 2005 [Page 25] Internet Draft PWE3 Applications & OAM Scenarios May 2005 | |------|............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). 7.2.1.3. Conclusion for Homogenous Services Expires November 2005 [Page 26] Internet Draft PWE3 Applications & OAM Scenarios May 2005 The choice for one option over the others is basically under the SP's 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... 7.2.2. Heterogenous Services A service is considered to be heterogenous 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 section 8.1.1. +----+ +----+ +-----+ | PE1|===============| PE2| +-----+ | |------|............PW1..........|--------| | | CE1 | | | | | | CE2 | Expires November 2005 [Page 27] Internet Draft PWE3 Applications & OAM Scenarios May 2005 | |------|............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 the layered model 7.2.2.1. Conclusion for Heterogenous 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". 8. Acknowledgments The authors would like to thank Richard Spencer, Neil Harrison, Monique Morrow, Tom Nadeau, Yaakov Stein, Mustapha Aissaoui & David McDysan for their comments on the draft. Expires November 2005 [Page 28] Internet Draft PWE3 Applications & OAM Scenarios May 2005 9. Security Considerations Security issues resulting from this draft will be discussed in greater depth at a later point. 10. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [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 [L2VPN-OAM-FRW] draft-mohan-sajassi-l2vpn-oam-req-frmk-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) 11. Author's Addresses Simon Delord France Telecom 2 av. Pierre Marzin 22300 LANNION, France E-mail: simon.delord@francetelecom.com Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France E-mail: philippe.niger@francetelecom.com Yuichi Ikejiri NTT Communications 1-6 Uchisaiwai-cho 1-chome Chiyoda-ku, Tokyo 100-8019 Japan Expires November 2005 [Page 29] Internet Draft PWE3 Applications & OAM Scenarios May 2005 E-mail: y.ikejiri@ntt.com Yuichiro Wada NTT Communications Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, JAPAN E-mail: yuichiro.wada@ntt.com Deborah Brungard ATT 200S. Laurel Ave. Middletown, NJ 07748 E-mail:dbrungard@att.com Lei Zhu Sprint 6220 Sprint Parkway Overland Park, Kansas 66251 E-Mail: 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, 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 radoaca@hotmail.com Ali Sajassi Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: sajassi@cisco.com 12. APPENDIXES Expires November 2005 [Page 30] Internet Draft PWE3 Applications & OAM Scenarios May 2005 12.1. Detailed description of each layer of the model 12.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. 12.1.2. E2E SP Layer This layer is composed of the two sub-layers: -A network sub-layer: this sub-layer 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, - Adaptation functions at CE level, - Interworking functions at PE level. These functionalities are implemented only in SP's 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. Expires November 2005 [Page 31] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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 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. 12.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). 13. Intellectual Property Statement 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. Expires November 2005 [Page 32] Internet Draft PWE3 Applications & OAM Scenarios May 2005 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. Disclaimer of Validity 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. 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. Expires November 2005 [Page 33]