Transcription

J-SPEC-001 / MEF 57Ethernet Ordering Technical SpecificationBusiness Requirements and Use CasesJoint StandardJuly 20171

As a leading technology and solutions development organization, the Alliance forTelecommunications Industry Solutions (ATIS) brings together the top global ICTcompanies to advance the industry’s most pressing business priorities. ATIS’ nearly 200member companies are currently working to address the All-IP transition, 5G, networkfunctions virtualization, big data analytics, cloud services, device solutions, emergencyservices, M2M, cyber security, network evolution, quality of service, billing support,operations, and much more. These priorities follow a fast-track development lifecycle —from design and innovation through standards, specifications, requirements, businessuse cases, software toolkits, open source solutions, and interoperability testing.ATIS is accredited by the American National Standards Institute (ANSI). The organizationis the North American Organizational Partner for the 3rd Generation Partnership Project(3GPP), a founding Partner of the oneM2M global initiative, a member of and major U.S.contributor to the International Telecommunication Union (ITU), as well as a member ofthe Inter-American Telecommunication Commission (CITEL). For more information, visitwww.atis.org.With over 210 leading member companies, including 130 service providers, MEF is aCalifornia, USA registered 501 c (3) industry association that is the enabling force for thedevelopment and implementation of agile, assured and orchestrated Third Networkservices for the digital economy and the hyper-connected world. Third Network servicesare delivered over automated, virtualized, and interconnected networks globally poweredby Carrier Ethernet 2.0 (CE 2.0), Lifecycle Service Orchestration (LSO), SDN, and NFV.MEF has established a technical and implementation framework that includesarchitecture, information models, service definitions, operational processes, open sourcecommunity, and certification programs. MEF work is conducted internally and -- under theguidance of the MEF UNITE program – in collaboration with global standardsorganizations and open source projects. See www.mef.net for more information.Notice of Disclaimer & Limitation of LiabilityThe information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand andinterpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. Norecommendation as to products or vendors is made or should be implied.NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT ORCONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER, NO REPRESENTATION OR WARRANTYIS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUALPROPERTY RIGHTS. ATIS SHALL NOT BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY ATIS FOR THISDOCUMENT, AND IN NO EVENT SHALL ATIS BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES.ATIS EXPRESSLY ADVISES THAT ANY AND ALL USE OF OR RELIANCE UPON THE INFORMATION PROVIDED IN THIS DOCUMENT IS ATTHE RISK OF THE USER.NOTE - The user’s attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. Bypublication of this standard, no position is taken with respect to whether use of an invention covered by patent rights will be required, and if any suchuse is required no position is taken regarding the validity of this claim or any patent rights in connection therewith.Please refer to [http://www.atis.org/legal/patentinfo.asp] and contact [email protected] to determine if any statement has been filed with ATIS orMEF by a patent holder indicating a willingness to grant a license either without compensation or on reasonable and non-discriminatory terms andconditions to applicants desiring to obtain a license.J-SPEC-001 / MEF 57, Ethernet Ordering Technical Specification, Business Requirements and Use Cases is an ATIS & MEF Joint Standarddeveloped by the ATIS Ordering Solutions Committee under the ATIS Ordering and Billing Forum (OBF) and the MEF Technical & OperationsCommittee.Published byAlliance for Telecommunications Industry Solutions1200 G Street, NW, Suite 500 Washington, DC 20005Published byMEF Forum6033 W. Century Blvd. Suite 1107 Los Angeles, CA 90045Copyright 2017 by Alliance for Telecommunications Industry Solutions and MEF ForumAll rights reserved.No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of thepublishers. For information contact ATIS at 1 202.628.6380 or MEF at 1 310.642.2800. ATIS is online at http://www.atis.org and MEF is online atwww.mef.net.2

Table of Contents1.List of Contributing Member Companies . 42.Abstract . 43.Terminology and Acronyms . 44.Scope . 75.Compliance Levels . 76.Introduction . 76.17.Product Order Scenarios . 8Ordering Use Cases and Business Process Definitions . 97.1High Level Use Cases . 97.2Order Management Scenarios . 178.Ordering Attributes . 188.1Access E-Line Product Ordering Attributes . 188.2UNI Ordering Attributes . 258.3Cancel In-Progress/Pending Order Use Case. 338.4Disconnect Use Case Attributes . 348.5Query In-Progress/Pending Order Use Case Attributes . 398.6Notify Order Status & Complete Order Use Case Attributes . 419.State Diagram . 4610.References . 483

1.List of Contributing Member CompaniesThe following Member companies of the MEF Forum and Alliance for Telecommunication Industry Solutions (ATIS)participated in the development of this document.Member CompaniesAT&TInnovative SystemsAmdocsLevel3Bell CanadaNational Exchange Carrier Association (NECA)CableLabsNational Information Solution Coop (NISC)CenturyLinkNeustar, Inc.Charter CommunicationsOracle CommunicationsComcastPCCW GlobalCommSoftPLDT Corp. Business SolutionsCommunications Data GroupSigma Systems CanadaCox CommunicationsSprintCreative Support SolutionsStrategic Options Business ConsultingCSG InternationalSynchronoss TechnologiesEricssonTDSFairPoint Communications, Inc.TEOCO CorpHawaiian TelcomT-MobileHorry Telephone Cooperative (HTC)VerizonHuaweiWest CorporationiconectivTable 1 - Contributing Member Companies2.AbstractThis document represents the cumulative work between MEF and ATIS Ordering and Billing Forum (OBF) to identifythe common ordering attributes and processes needed to support inter-carrier Product Ordering of Ethernet Servicesworldwide. This document supports the requirements defined in the MEF Lifecycle Service Orchestration (LSO)Reference Architecture and Framework (MEF 55, “LSO RA”) requirements for Ordering over the Sonata interface(Service Provider - Partner interactions). Information contained within this document will be utilized by bothBuyer and Seller ordering systems for the development of automated API systems.3.Terminology and AcronymsThis section defines the terms used in this document. In many cases, the normative definitions to terms are found inother documents. In these cases, the third column is used to provide the reference that is controlling, in other MEF orexternal documents.4

The following standards and specifications contain provisions that, through reference in this text, constitute provisionsof this Specification. At the time of publication, the editions indicated were valid. All standards and specifications aresubject to revision, and parties to agreements based on this Specification are encouraged to investigate the possibilityof applying the most recent editions of the standards and specifications indicated below.TermDefinitionReferenceAccess E-LineAn E-Access Service, based on the O-Line Service definition.MEF 51ApplicationProgram Interface(API)In the context of Lifecycle Service Orchestration (LSO), API describes one of theManagement Interface Reference Points based on the requirements specified in anInterface Profile, along with a data model, the protocol that defines operations on thedata and the encoding format used to encode data according to the data model.MEF 55BuyerUsing MEF 55 terminology, a Buyer may be a Customer or a Service Provider who isbuying from a Partner. For the purposes of this document, a Buyer is the ServiceProvider who is ordering from a Partner (aka, Seller).ThisdocumentBuyer OrderA commercial document which may be electronically transmitted, and first official offerissued by a Buyer to a Seller, indicating types, quantities, and agreed prices forproducts or services.ThisdocumentBusiness RuleA Seller defined constraint or validation that is implemented as part of the Orderacceptance and handling process. Business rules are used to ensure accuracy ofOrder data and enforce MEF-defined rules in a way that aligns with the product offeringspecifications.ThisdocumentCarrier EthernetNetwork (CEN)A network from a Service Provider or network operator supporting the MEF service andarchitecture models.MEF 12.1Class of Service(COS)A designation given to one or more sets of performance objectives and associatedparameters by the Service Provider.MEF 10.3CLLI CodeA CLLI Code is an eleven character, standardized, geographic identifier whichuniquely identifies the geographic location and certain functional categories ofequipment.ATIS0300253CustomerA Customer is the organization purchasing, managing, and/or using ConnectivityServices from a Service Provider. This may be an end-user business organization,mobile operator, or a partner network operator.MEF 55Data ModelA mapping of the contents of an information model into a form that is specific to aparticular type of data store or repository. A "data model" is basically the rendering ofan information model according to a specific set of mechanisms for representing,organizing, storing and handling data.IETF RFC3198End CustomerThe name of the end (retail) customer for the UNI.ThisdocumentEthernet VirtualConnection (EVC)An association of two or more Ethernet UNIs.MEF 4ExternalNetwork-to-NetworkInterface (ENNI)A reference point representing the boundary between two Operator networks that areoperated as separate administrative domains.MEF 26.25

TermDefinitionReferenceGeographic PointA geometric point on Earth, which can include a latitude, longitude, and elevation,corresponding to the location of service, such as a Site Address, a Site CLLI Code or aSite Geographic Point.ThisdocumentInformation ModelAn abstraction and representation of the entities in a managed environment, theirproperties, attributes and operations, and the way that they relate to each other. It isindependent of any specific repository, software usage, protocol, or platform.IETF RFC3198Interface ProfileDefines the structure, behavior, and semantics supporting a specific ManagementInterface Reference Point as identified in the LSO Reference Architecture (MEF 55).The Interface Profile specification contains all the necessary information to implementthe related API, including objects, attributes, operations, notifications, and parameters.MEF 55O-Line ServiceA General OVC Service that uses a Point-to-Point OVC.MEF 51Operator VirtualConnection (OVC)An association of OVC End PointsMEF 26.2OVC End PointsA logical entity at a given External Interface that is associated with a distinct set offrames passing over that External Interface i.e., UNI, ENNI.MEF 26.2PartnerAn organization providing Products and Services to the Service Provider (Buyer) inorder to allow the Service Provider to instantiate and manage Service Componentsexternal to the Service Provider domain.MEF 55ScenarioA narrative of foreseeable interactions of actors and the system under design. AScenario describes one way that a system is or is envisaged to be used in the contextof activity in a defined time-frame.WikipediaSellerUsing MEF 55 terminology, a Seller may be a Service Provider or a Partner who isproviding service to a Buyer. For the purposes of this document, a Seller is the Partnerwho is providing the product to the Buyer.ThisdocumentService ComponentA segment or element of a Service that is managed independently by the ServiceProvider.MEF 55In the context of Ethernet Ordering, when a Buyer wishes to order only a portion of anEthernet Service, the portion being ordered is called a “component” or “servicecomponent”. For example, a Buyer may wish to order just a UNI without an associationto an EVC or OVC.Service LevelAgreement (SLA)The contract between the Customer and Service Provider or Operator specifying theagreed to service level commitments and related business agreements.MEF 10.3Service ProviderThe organization providing Ethernet Service(s).MEF 10.3Service ProviderBuyer IdentifierThe ID of the Service Provider (Buyer) organization placing the order.ThisdocumentStandalone UNIIn the context of Ethernet Ordering, a Standalone UNI is a request by the Buyer to theSeller for a User Network Interface (UNI) that has no association to an EVC or OVC.These types of orders are typically done to build out locations in advance of servicedelivery requirements or to groom network capacity.ThisdocumentUser NetworkInterface (UNI)The physical demarcation point between the responsibility of the Service Provider andthe responsibility of the Subscriber.MEF 10.36

4.TermDefinitionReferenceUnified ModelingLanguage (UML)Unified Modeling Language (UML) is a graphical language for visualizing,specifying, constructing, and documenting the artifacts of a software-intensive system.The UML offers a standard way to write a system's blueprints, including conceptualthings such as business processes and system functions as well as concrete thingssuchas programming language statements, database schemas, and reusable nified OrderingModel (UOM)UOM describes a complete set of system documentation using an end-to-endstructured methodology. The scope of UOM encompasses business requirements,analysis, design, and implementation.ATISTerminologyUse CaseIn UML, Use Cases are a means to capture the requirements of systems, i.e., whatsystems are supposed to do. Each Use Case’s subject represents a system underconsideration to which the Use Case applies. A Use Case is a specification ofbehavior.Table 2 - Terminology and AcronymsOMG UML2.5ScopeThis specification defines the process for MEF Carrier Ethernet order negotiation/management between aPartner/Access Provider (Seller) and Service Provider (Buyer). The Ethernet Ordering specification will be based onMEF defined services and is intended to be used internationally. The requirements for Ethernet Ordering will bedeveloped following a UML process approach which includes, but is not limited to, Business Process Flows, UseCases, Scenarios, Information Models, and State Machine Diagrams. This specification is limited to the businessprocess requirements depicted as Use Cases and attribute definitions needed for Ethernet Ordering. It will be the basisof requirements for a Product Order Data Model and API.5.Compliance LevelsThe requirements that apply to the functionality of this document are specified in the following sections. Items that areREQUIRED (contain the words MUST or MUST NOT) will be labeled as [Rx]. Items that are RECOMMENDED (containthe words SHOULD or SHOULD NOT) will be labeled as [Dx]. Items that are OPTIONAL (contain the words MAY orOPTIONAL) will be labeled as [Ox].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. All keywords use upper case, bold text to distinguish them from other uses of the words. Any use of these key words (e.g.,may and optional) without [Rx], [Dx] or [Ox] is not normative.6.IntroductionThis specification defines the business requirements and process-related guidelines for the Ordering process over theSonata interface. The Sonata interface is defined in MEF 55 as the Management Interface Reference Point supportingthe management and operations interactions (e.g., ordering, billing, trouble management, etc.) between two networkproviders (e.g., Service Provider Domain and Partner Domain). The scope of this document is limited to interactionsbetween these parties; within this document, they are referred to as the “Buyer” and the “Seller”.To fully define the business interactions associated with inter-carrier ordering, this document is focused on the followingkey areas: Section 7 defines the Use Cases and Order Management Scenarios, Section 8 defines the specific ordering7

attributes associated with the product orders supported in this document and Section 9 provides the State Diagram forProduct Ordering. Implementation details will be separately published in an Interface Profile Specification.Figure 1 - Lifecycle Service Orchestration Reference Architecture (LSO RA) diagramFigure 1 depicts the Ethernet Ordering process alignment with the LSO RA, per MEF 55. This document addressesthe interactions between the business applications of the Service Provider (“Buyer”) and Partner domains (“Seller”)required to support the buying and selling of Ethernet Services. Various supporting business functions may be utilizedprior to initiation of the ordering process. Those functions are outside the scope of this document.It is important to note that specifications related to Service Provider-Partner interactions without the submission of aProduct Order are also outside the scope of this document. Therefore, if non-Order impacting changes to an EthernetService are permitted, those changes could be exchanged over the Interlude interface and would not follow therequirements specified in this document.6.1 Product Order ScenariosProduct Ordering requirements for the following MEF Ethernet Services and/or service components are supported inthis version of the document: Access E-LineStandalone UNIIn addition, some Use Cases and associated requirements are generic in nature and have been defined in a mannerthat supports all MEF Ethernet Services. Those requirements which support more than Access E-Line have beennoted in the Use Case description.Future versions of this document will expand the requirements to fully define all MEF Ethernet Services that areordered via the Sonata interface.8

7.Ordering Use Cases and Business Process Definitions7.1High Level Use CasesThis section provides the complete set of Use Cases needed to support the ordering of Ethernet Services andexpands on the ordering process defined in MEF 50 (Carrier Ethernet Service Lifecycle Process Model). These UseCases are based on business process standards of interactivity between ordering entities and providers. Each usecase drives the need for specific ordering information blocks, and administrative process tracking objects. The specificattributes associated with each Use Case are defined in Section 8. Prior arrangements for Buyer authentication,security verification and system interface requirements are not addressed within these use cases. All onboardingrequirements must be defined and negotiated between the Buyer and Seller prior to the submission of any Ethernetorders.It is expected that a catalog will be utilized to identify all products and services available for each Buyer. The catalogmay provide the ability for a Buyer to purchase an entire product with all associated components as well as theprocurement of various elements that comprise that specific service such as the business process of ordering aphysical UNI for future use, but not ordering an EVC or OVC to that UNI in the order itself. The requirements for how acatalog is used within the ordering process are outside the scope of this document.7.1.1 Product Order Management Use CasesThis section defines the use cases that support the end-to-end lifecycle of Product Ordering of Ethernet Services. Theterm “service” within this document pertains to the deployed Carrier Ethernet Service realized as a result of a ProductOrder.Figure 2 - MEF Product Order Management Use CasesFigure 2 indicates which party may initiate the process defined in the Use Case.9

UseCase#Use Case NameUse Case Description1Create New OrderA request initiated by the Buyer to order a new product or servicecomponent(s).2Create ChangeOrderA request initiated by the Buyer or Seller to order a modification/change to anexisting active service or service component(s).3Create DisconnectOrderA request initiated by the Buyer or Seller to terminate (e.g., disconnect)existing active service(s) or service component(s).4QueryIn-Progress/Pending OrderStatusA request initiated by the Buyer to request the status of an open/pendingorder. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3.5AmendIn-Progress/PendingOrderA request initiated by the Buyer to modify/amend an in-progress/pendingorder. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3.6CancelIn-Progress/PendingOrderA request initiated by the Buyer or Seller to cancel an in-progress/pendingorder. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3.7Notify Order StatusA notification initiated by the Seller to the Buyer providing subsequent statusinformation on “Acknowledged” orders such as service delivery confirmation,error, and/or jeopardy messages. This Use Case is only applicable afterinitiation of Use Case # 1, 2, or 3.8Complete OrderA notification initiated by the Seller to the Buyer to close an inprogress/pending order. This use case notifies the Buyer the service is nowactivated and no further actions are required. This Use Case is only applicableafter initiation of Use Case # 1, 2, or 3.Table 3 - MEF Product Order Management Use Case Summary7.1.1.1 Order Management Use Case DescriptionsThis section defines the details for each of the order management Use Cases.FieldDescriptionUse Case #1Use CaseNameCreate New OrderDescriptionA request initiated by the Buyer to order a new product or service component(s).ActorsBuyer, Seller10

Pre-Conditions1. Buyer must be authorized to purchase products from the Seller (Buyer on-boarded)2. Buyer may have completed pre-order inquiries/serviceability request.3. Buyer may have completed a quoting process to obtain pricing information.Process Steps1.2.3.4.Post-Conditions1. The "Acknowledged" order is ready for processing including additional business rulevalidation.2. Seller initiates order processing and notifies the Buyer of commitment to provide therequested product by a specific date.AlternativePaths1. If fatal errors are encountered in the validation step, the Seller returns all identifiederrors in a reject response and the Buyer may submit a new order. Fatal errors mayinclude validations such as malformed request (invalid payload), software applicationis not available and/or security/authentication violation failures. The status of the Orderis set to "Rejected" by the Seller.Assumptions1. The electronic method for sending the order will be the same as the electronicmethod for sending the responses.2. The Buyer has determined target Seller (Partner/Access Provider). Partner selectionis out-of-scope.3. The Buyer and the Seller have established a partnership agreement (which mightinclude ENNI inventory).The Buyer initiates and submits a new order.The Seller's gateway receives a new order.The Seller validates the new order.The Seller accepts the new order and provides a response with an assigned SellerOrder ID. The status of the Order is set to “Acknowledged” by the Seller.ReferencesATIS/OBF Use Case Mapping: Service Request Placement/Pre-Validation (UOM-ASRVolume I)FieldDescriptionUse Case #2Use CaseNameCreate Change OrderDescriptionA request initiated by the Buyer or Seller to order a modification/change to an existing activeproduct or service component(s), such as: Adding or removing components to or from an existing service (e.g.adding/removing a leg to an existing EPL) Modifying attributes of an existing service or service components (e.g. EVCbandwidth change, Telecommunication Service Priority (TSP)/restoration priorityidentifier). Modifying service demarcation point of an existing service (e.g. rehome EVC'sfrom one UNI to another UNI, change physical port) Administrative changes to an existing service (e.g. changing billing address ofservice).Note: this is a list of possible scenarios; other scenarios may exist.This use case supports all MEF Services, not just Access E-Line.11

ActorsBuyer, SellerPre-Conditions1.2.3.4.The product being modified is already allocated or activated and in-service.An authorized Buyer/Seller must initiate the change of an in-service product.Buyer may have completed pre-order inquiries/serviceability request.Buyer may have completed a quoting process to obtain pricing information.Process Steps1.2.3.4.The Buyer/Seller initiates a change order.The Seller's gateway receives a change order.The Seller validates the change order.The Seller accepts the change order and provides a response with an assigned SellerID. The status of the Order is set to “Acknowledged” by the Seller.Post-Conditions1. The “Acknowledged” order is ready for processing including additional business rulevalidation.2. Seller initiates order processing and notifies the Buyer of commitment to provide therequested product by a specific date.AlternativePaths1. If fatal errors are encountered in the validation step, the Seller returns all identifiederrors in a reject response and the Buyer may submit a new change order. Fatalerrors may include validations such as malformed request (invalid payload), softwareapplication is not available and/or security/authentication violation failures. The statusof the Order is set to "Rejected" by the Seller.Assumptions1. The electronic method for sending the order will be the same as the electronic methodfor sending the responses.2. The Seller may provide business requirements to the Buyer stipulating rules for thesubmission of a Change Order and submission of multiple Change Orders.ReferencesATIS/OBF Use Case Mapping: Service Request Placement/Pre-Validation (UOM-ASRVolume I)FieldDescriptionUse Case #3Use CaseNameCreate Disconnect OrderDescriptionA request initiated by the Buyer or Seller to terminate (e.g., disconnect) an existing activeservice(s) or service component(s).This use case supports all MEF Services, not just Access E-Line.ActorsBuyer, SellerPre-Conditions1. The service(s) being disconnected is/are already activated and in-service.2. An authorized Buyer/Seller must initiate the disconnect of an in-service product.Process Steps1. The Buyer/Seller initiates a disconnect order

member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, qualit