1、1 J-SPEC-001 / MEF 57 Ethernet Ordering Technical Specification Business Requirements and Use Cases Joint Standard July 2017 2 As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to
2、 advance the industrys most pressing business priorities. ATIS nearly 200 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, q
3、uality of service, billing support, operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is ac
4、credited by the American National Standards Institute (ANSI). The organization is 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 Telecommunica
5、tion Union (ITU), as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. With over 210 leading member companies, including 130 service providers, MEF is a California, USA registered 501 c (3) industry association that is the enabling
6、 force for the development and implementation of agile, assured and orchestrated Third Network services for the digital economy and the hyper-connected world. Third Network services are delivered over automated, virtualized, and interconnected networks globally powered by Carrier Ethernet 2.0 (CE 2.
7、0), Lifecycle Service Orchestration (LSO), SDN, and NFV. MEF has established a technical and implementation framework that includes architecture, information models, service definitions, operational processes, open source community, and certification programs. MEF work is conducted internally and -
8、under the guidance of the MEF UNITE program in collaboration with global standards organizations and open source projects. See for more information. Notice of Disclaimer within this document, they are referred to as the “Buyer” and the “Seller”. To fully define the business interactions associated
9、with inter-carrier ordering, this document is focused on the following key areas: Section 7 defines the Use Cases and Order Management Scenarios, Section 8 defines the specific ordering 8 attributes associated with the product orders supported in this document and Section 9 provides the State Diagra
10、m for Product Ordering. Implementation details will be separately published in an Interface Profile Specification. Figure 1 depicts the Ethernet Ordering process alignment with the LSO RA, per MEF 55. This document addresses the interactions between the business applications of the Service Provider
11、(“Buyer”) and Partner domains (“Seller”) required to support the buying and selling of Ethernet Services. Various supporting business functions may be utilized prior to initiation of the ordering process. Those functions are outside the scope of this document. It is important to note that specificat
12、ions related to Service Provider-Partner interactions without the submission of a Product Order are also outside the scope of this document. Therefore, if non-Order impacting changes to an Ethernet Service are permitted, those changes could be exchanged over the Interlude interface and would not fol
13、low the requirements specified in this document. 6.1 Product Order Scenarios Product Ordering requirements for the following MEF Ethernet Services and/or service components are supported in this version of the document: Access E-Line Standalone UNI In addition, some Use Cases and associated requirem
14、ents are generic in nature and have been defined in a manner that supports all MEF Ethernet Services. Those requirements which support more than Access E-Line have been noted in the Use Case description. Future versions of this document will expand the requirements to fully define all MEF Ethernet S
15、ervices that are ordered via the Sonata interface. Figure 1 - Lifecycle Service Orchestration Reference Architecture (LSO RA) diagram 9 7. Ordering Use Cases and Business Process Definitions 7.1 High Level Use Cases This section provides the complete set of Use Cases needed to support the ordering o
16、f Ethernet Services and expands on the ordering process defined in MEF 50 (Carrier Ethernet Service Lifecycle Process Model). These Use Cases are based on business process standards of interactivity between ordering entities and providers. Each use case drives the need for specific ordering informat
17、ion blocks, and administrative process tracking objects. The specific attributes 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 onboarding requi
18、rements must be defined and negotiated between the Buyer and Seller prior to the submission of any Ethernet orders. It is expected that a catalog will be utilized to identify all products and services available for each Buyer. The catalog may provide the ability for a Buyer to purchase an entire pro
19、duct with all associated components as well as the procurement of various elements that comprise that specific service such as the business process of ordering a physical UNI for future use, but not ordering an EVC or OVC to that UNI in the order itself. The requirements for how a catalog is used wi
20、thin the ordering process are outside the scope of this document. 7.1.1 Product Order Management Use Cases This section defines the use cases that support the end-to-end lifecycle of Product Ordering of Ethernet Services. The term “service” within this document pertains to the deployed Carrier Ether
21、net Service realized as a result of a Product Order. Figure 2 - MEF Product Order Management Use Cases Figure 2 indicates which party may initiate the process defined in the Use Case. 10 Use Case # Use Case Name Use Case Description 1 Create New Order A request initiated by the Buyer to order a new
22、product or service component(s). 2 Create Change Order A request initiated by the Buyer or Seller to order a modification/change to an existing active service or service component(s). 3 Create Disconnect Order A request initiated by the Buyer or Seller to terminate (e.g., disconnect) existing active
23、 service(s) or service component(s). 4 Query In-Progress/ Pending Order Status A request initiated by the Buyer to request the status of an open/pending order. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3. 5 Amend In-Progress/Pending Order A request initiated by the Buy
24、er to modify/amend an in-progress/pending order. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3. 6 Cancel In-Progress/Pending Order A request initiated by the Buyer or Seller to cancel an in-progress/pending order. This Use Case is only applicable after initiation of Use
25、Case # 1, 2, or 3. 7 Notify Order Status A notification initiated by the Seller to the Buyer providing subsequent status information on “Acknowledged” orders such as service delivery confirmation, error, and/or jeopardy messages. This Use Case is only applicable after initiation of Use Case # 1, 2,
26、or 3. 8 Complete Order A notification initiated by the Seller to the Buyer to close an in-progress/pending order. This use case notifies the Buyer the service is now activated and no further actions are required. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3. Table 3 - M
27、EF Product Order Management Use Case Summary 7.1.1.1 Order Management Use Case Descriptions This section defines the details for each of the order management Use Cases. Field Description Use Case # 1 Use Case Name Create New Order Description A request initiated by the Buyer to order a new product o
28、r service component(s). Actors Buyer, Seller 11 Pre-Conditions 1. 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. Proc
29、ess Steps 1. The Buyer initiates and submits a new order. 2. The Sellers gateway receives a new order. 3. The Seller validates the new order. 4. The Seller accepts the new order and provides a response with an assigned Seller Order ID. The status of the Order is set to “Acknowledged” by the Seller.
30、Post-Conditions 1. The “Acknowledged“ order is ready for processing including additional business rule validation. 2. Seller initiates order processing and notifies the Buyer of commitment to provide the requested product by a specific date. Alternative Paths 1. If fatal errors are encountered in th
31、e validation step, the Seller returns all identified errors in a reject response and the Buyer may submit a new order. Fatal errors may include validations such as malformed request (invalid payload), software application is not available and/or security/authentication violation failures. The status
32、 of the Order is set to “Rejected“ by the Seller. Assumptions 1. The electronic method for sending the order will be the same as the electronic method for sending the responses. 2. The Buyer has determined target Seller (Partner/Access Provider). Partner selection is out-of-scope. 3. The Buyer and t
33、he Seller have established a partnership agreement (which might include ENNI inventory). References ATIS/OBF Use Case Mapping: Service Request Placement/Pre-Validation (UOM-ASR Volume I) Field Description Use Case # 2 Use Case Name Create Change Order Description A request initiated by the Buyer or
34、Seller to order a modification/change to an existing active product 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. EVC bandwidth cha
35、nge, Telecommunication Service Priority (TSP)/restoration priority identifier). Modifying service demarcation point of an existing service (e.g. rehome EVCs from one UNI to another UNI, change physical port) Administrative changes to an existing service (e.g. changing billing address of service). No
36、te: this is a list of possible scenarios; other scenarios may exist. This use case supports all MEF Services, not just Access E-Line. 12 Actors Buyer, Seller Pre-Conditions 1. The product being modified is already allocated or activated and in-service. 2. An authorized Buyer/Seller must initiate the
37、 change of an in-service product. 3. Buyer may have completed pre-order inquiries/serviceability request. 4. Buyer may have completed a quoting process to obtain pricing information. Process Steps 1. The Buyer/Seller initiates a change order. 2. The Sellers gateway receives a change order. 3. The Se
38、ller validates the change order. 4. The Seller accepts the change order and provides a response with an assigned Seller ID. The status of the Order is set to “Acknowledged” by the Seller. Post-Conditions 1. The “Acknowledged” order is ready for processing including additional business rule validatio
39、n. 2. Seller initiates order processing and notifies the Buyer of commitment to provide the requested product by a specific date. Alternative Paths 1. If fatal errors are encountered in the validation step, the Seller returns all identified errors in a reject response and the Buyer may submit a new
40、change order. Fatal errors may include validations such as malformed request (invalid payload), software application is not available and/or security/authentication violation failures. The status of the Order is set to “Rejected“ by the Seller. Assumptions 1. The electronic method for sending the or
41、der will be the same as the electronic method for sending the responses. 2. The Seller may provide business requirements to the Buyer stipulating rules for the submission of a Change Order and submission of multiple Change Orders. References ATIS/OBF Use Case Mapping: Service Request Placement/Pre-V
42、alidation (UOM-ASR Volume I) Field Description Use Case # 3 Use Case Name Create Disconnect Order Description A request initiated by the Buyer or Seller to terminate (e.g., disconnect) an existing active service(s) or service component(s). This use case supports all MEF Services, not just Access E-L
43、ine. Actors Buyer, Seller Pre-Conditions 1. 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 Steps 1. The Buyer/Seller initiates a disconnect order with order items of the same or d
44、ifferent MEF Services. It is recommended that no more than 20 order items be submitted on a single disconnect order. 2. The Sellers gateway receives a disconnect order. 3. The Seller validates the disconnect order and associated order items. 13 4. The Seller accepts the disconnect order and provides
45、 a response with an assigned Seller Order ID. The status of the Order is set to “Acknowledged” by the Seller. Post-Conditions 1. The “Acknowledged” order is ready for processing including additional business rule validation. 2. Seller initiates order process and notifies Buyer of commitment to provi
46、de the requested product by a specific date. Alternative Paths 1. If fatal errors are encountered in the validation step, the Seller returns all identified errors in a reject response and the Buyer may submit a new disconnect order. Fatal errors may include validations such as malformed request (inv
47、alid payload), determination of non-eligible order items, software application is not available and/or security/authentication violation failures. The status of the Order is set to “Rejected“ by the Seller. Assumptions 1. The electronic method for sending the order will be the same as the electronic
48、 method for sending the responses. 2. Any order item on the disconnect order will not have another service associated to it. 3. Individual Seller business rules will enforce any limit on the amount of order items that can be requested for disconnect on a single order. References ATIS/OBF Use Case Ma
49、pping: Service Request Placement/Pre-Validation (UOM-ASR Volume I) Field Description Use Case # 4 Use Case Name Query In-Progress/Pending Order Status Description A request initiated by the Buyer to request the status of an open/pending order. This Use Case is only applicable after initiation of Use Case # 1, 2, or 3. This use case supports all MEF Services, not just Access E-Line. Actors Buyer, Seller Pre-Conditions 1. The Buyer must be authorized to perform the inquiry. 2. An in-progress/pending order exists in the Sellers system, and the Seller has ini
