Introducing the Specifications of the Metro Ethernet Forum

1. Introducing the Specifications of the Metro Ethernet Forum

3. This Presentation

4. MEF 7: EMS - NMS Information Model A specification Enable consistent definition of the management information required to manage Carrier Ethernet. A Model defines the specific EMS-NMS management interface using a well-defined method such as Common Object Request Broker Object (CORBA) IDL, Simple Network Management Protocol (SNMP), JAVA, XML, etc. Scope Ethernet (ETH) layer UNI configuration provisioning ETH layer configuration and provisioning ETH layer network connection and fault management (including setup/modification, notification, testing) MEF 7 defines an Element Management System to Network Management System informational model. This model defines the concepts and mechanisms required for a carrier to manage an Ethernet service. Its scope is limited to defining Ethernet (ETH) layer UNI configuration provisioning ,ETH layer configuration and provisioning, and ETH layer network connection and fault management (including setup/modification, notification, testing). MEF 7 defines an Element Management System to Network Management System informational model. This model defines the concepts and mechanisms required for a carrier to manage an Ethernet service. Its scope is limited to defining Ethernet (ETH) layer UNI configuration provisioning ,ETH layer configuration and provisioning, and ETH layer network connection and fault management (including setup/modification, notification, testing).

5. MEF Services OAM MEF 7 defines a Means to provide OAM at the Ethernet Services layer Does not define OAM at the transport link/ network layers Compliments/relies on the work done in the ITU, IEEE and IETF at the Transport data link and Network layers Provides a frame work and concepts for managing and monitoring flows across a connectionless network from end to end Provides mechanism to perform: Node Discovery, Establish connectivity, monitor CoS, and detect service impairments MEF 7’s informational model is intended to begin the process of defining a means to provide OAM at the Ethernet services layer. Its is not to be used instead of other network or transport layer OAM mechanisms but in addition to them. It relies on the existence of these underlying mechanisms to perform its task of Ethernet Node Discovery, Connectivity establishment and service level performance monitoringMEF 7’s informational model is intended to begin the process of defining a means to provide OAM at the Ethernet services layer. Its is not to be used instead of other network or transport layer OAM mechanisms but in addition to them. It relies on the existence of these underlying mechanisms to perform its task of Ethernet Node Discovery, Connectivity establishment and service level performance monitoring

6. Key Assumptions behind MEF OAM The MEF 7 is based on several assumptions –some of which are assumed within the specification but are articulated here. These assumptions transcend MEF 7 and will apply to future work as well.The MEF 7 is based on several assumptions –some of which are assumed within the specification but are articulated here. These assumptions transcend MEF 7 and will apply to future work as well.

7. Network Layering Concepts Flows, connections and resources can all be managed separately at each LND Each can remain independent Each in turn can pass information to upper management domains to isolate issues. This Model works to the MEF’s purposes of concentrating on the Ethernet service layer and rely on work done at other layers and in other stds bodies. It does however require tight inter stds body alignment.This Model works to the MEF’s purposes of concentrating on the Ethernet service layer and rely on work done at other layers and in other stds bodies. It does however require tight inter stds body alignment.

8. MEF 7Network Mgmt Functions Addressed NMS Functional Model Node Discovery Service performance monitoring Ethernet (ETH) layer MEN topology configuration and provisioning ETH layer UNI configuration and provisioning ETH layer network flow (EVC) management ETH layer fault management The rest of the presentation details the concepts behind each of the model’s elements.The rest of the presentation details the concepts behind each of the model’s elements.

9. NMS Functional Model NMS Monitors/controls service end to end across separate EMS monitored/controlled flow domains The Network View provides an abstraction of network resources allowing for flexibility in the management of the network. It provides a network layering abstraction, allowing multiple network technologies to be managed in an integrated fashion. The network view abstraction allows for the representation of a topological view of network resources, and the management of end-to-end connections or flows across the network. The network view abstraction resides at the Network Management Layer (NML) of TMN. The network view abstraction provides more service, flow, and connection oriented information than Element Management Layer (EML) and Element Layer (EL) nodal oriented management information models.The Network View provides an abstraction of network resources allowing for flexibility in the management of the network. It provides a network layering abstraction, allowing multiple network technologies to be managed in an integrated fashion. The network view abstraction allows for the representation of a topological view of network resources, and the management of end-to-end connections or flows across the network. The network view abstraction resides at the Network Management Layer (NML) of TMN. The network view abstraction provides more service, flow, and connection oriented information than Element Management Layer (EML) and Element Layer (EL) nodal oriented management information models.

10. Network Concepts MEF 7 relies closely on the concepts defined by the ITU in G.809 Ethernet services are inherently connectionless Services are supported over Flows Flow Domains can be set up within a providers network and interconnected Useful for connection of separate underlying transport networks (SONET, vs. Switched etc..) Flow Domains can also be connected between carrier networks MEF 7 as the assumptions previously stated defines Ethernet services as connectionless. The ITU in March 2003 released G.809 which describes the concepts for managing connectionless services. MEF 7 in turn uses G.809’s Flow and Flow Domain concepts to build the required flexible layered management frame work that allows for service management to take place over multiple transport and network domains.MEF 7 as the assumptions previously stated defines Ethernet services as connectionless. The ITU in March 2003 released G.809 which describes the concepts for managing connectionless services. MEF 7 in turn uses G.809’s Flow and Flow Domain concepts to build the required flexible layered management frame work that allows for service management to take place over multiple transport and network domains.

11. Flow Domain Partitioning Concept Flow Domains are sub networks – interconnected by network links Flow domains can be partitioned and nested within other larger flow domains E.g. each can be managed by separate EMS and/or NOCs NMS systems can manage across multiple domains at the service layer Builds an ECO system for management that allows the service view to be separate but potentially linked to the underlying element and link level views. E.g. Allows end to end service monitoring, and when a service level problem is detected allows for element level isolation.Builds an ECO system for management that allows the service view to be separate but potentially linked to the underlying element and link level views. E.g. Allows end to end service monitoring, and when a service level problem is detected allows for element level isolation.

12. Provisioning, Flow, Connection Management Terminations of links between flow domains are called Flow Point Pools (FPPs) or Link Ends FPPs can be associated with trail ends within a sub network topology )Fig. 1) A subnetwork connection is terminated by Connection Termination Points (CTPs) Multiple subnetworks can make up a flow domain link as depicted in Fig. 2

13. Relationship Diagrams Information is provided in the specifications with respect to the relationship to the concepts defined. These cover: ETH Topology Information ETH Connectivity Information Association Relationship of ETH Topology Information Association Relationship of ETH Connection Information The following three slides provide information on the topology, Entity information, and the performance parameters collected through the MEF OAM Model.The following three slides provide information on the topology, Entity information, and the performance parameters collected through the MEF OAM Model.

14. Applying the Model The following are a selection of examples covering: Discovery Control Performance monitoring The following 7 slides provide examples of how the models concepts can be executed for discover, control and monitoring functions.The following 7 slides provide examples of how the models concepts can be executed for discover, control and monitoring functions.

15. On-Demand retrieval of Ethernet Flow Domains TRIGGER: The NMS initiates this operation to inventory all Ethernet Flow Domains managed by the EMS, and retrieve certain attributes from each. PRE-CONDITIONS: EMS-NMS Connectivity is established. NMS learns of all the Flow domains managed by an EMSNMS learns of all the Flow domains managed by an EMS

16. On-Demand retrieval of Ethernet UNIs TRIGGER: The NMS initiate this operation to inventory all Ethernet UNIs managed by the EMS, and retrieve certain attributes from each. PRE-CONDITIONS: EMS-NMS Connectivity is established. The NMS is aware of or able to retrieve the names or identifiers for all Ethernet UNI instances. NMS can inventory all Ethernet UNIS managed by each connected EMSNMS can inventory all Ethernet UNIS managed by each connected EMS

17. Auto-discovery of Ethernet FPP UNIs TRIGGER: Whenever a new Ethernet FPP is created, the EMS notifies the NMS and provides attribute information. PRE-CONDITIONS: EMS-NMS Connectivity is established. NMS can automatically be updated by the EMS when an Ethernet Flow Provisioning Point is createdNMS can automatically be updated by the EMS when an Ethernet Flow Provisioning Point is created

18. On-Demand retrieval of Ethernet EVCs TRIGGER: The NMS initiate this operation to inventory all Ethernet EVCs and associated ETH_Flow_Points within a subnetwork managed by the EMS, and retrieve certain attributes from each. NMS can inventory all Ethernet EVCs within a subnetworkNMS can inventory all Ethernet EVCs within a subnetwork

19. Create a Point-to-Point EVC TRIGGER: The NMS has provisioned an ETH_FPP_UNI representing an Ethernet UNI on a port, and is ready to create a EVC to support the customer’s service. Allow the NMS to provision an EVC through an Ethernet Flow domain- between multiple network elementsAllow the NMS to provision an EVC through an Ethernet Flow domain- between multiple network elements

20. Change Ethernet Flow Point EVC Ingress COS Profile TRIGGER: The NMS has a need to revise the COS Profile on an Ethernet Flow Point due to a change order. Allows the NMS to change/update the CoS profile parameters on and EFPAllows the NMS to change/update the CoS profile parameters on and EFP

21. Receiving Ethernet Flow Point Related Alarms TRIGGER: An alarm notification is sent to the NMS whenever an alarmable event is detected by the EMS or NE NMS can inventory all Ethernet UNIS managed by each connected EMSNMS can inventory all Ethernet UNIS managed by each connected EMS

22. OAM Frame Requirements Requires its own in band OAM “ data channel” To perform operations Service pings Carry service provisioning and performance data Like an ECC Identifiable by Multicast Destination address and/or Ether Type field While not directly called out in MEF 7 a mechanism is required to communicate OAM information between Ethernet service bearing elements and domains. This slide depicts one leading mechanism for performing the functions outlined within MEF 7.While not directly called out in MEF 7 a mechanism is required to communicate OAM information between Ethernet service bearing elements and domains. This slide depicts one leading mechanism for performing the functions outlined within MEF 7.

23. Discovery Requirements The MEF OAM informational model can be leveraged to provide discovery of all connected network elements. Multicast ping leverages Ethernet Multicast capabilities to reach all connected elements and illicit a responseThe MEF OAM informational model can be leveraged to provide discovery of all connected network elements. Multicast ping leverages Ethernet Multicast capabilities to reach all connected elements and illicit a response

24. Connectivity, Latency, Loss Discovery can be accomplished leveraging Ethernets inherent “learning capabilities” Connectivity can be verified with Unicast pingDiscovery can be accomplished leveraging Ethernets inherent “learning capabilities” Connectivity can be verified with Unicast ping

25. Delay Variation Delay variation can be measured by using time stamped ping packets and measuring the difference in the sent and received time intervals. Note this concept and other MEF Ethernet service performance parameters are defined in MEF 10.Delay variation can be measured by using time stamped ping packets and measuring the difference in the sent and received time intervals. Note this concept and other MEF Ethernet service performance parameters are defined in MEF 10.

26. Summary

27. For Full Details …