CCAMP Working Group Haomian Zheng Internet Draft Huawei Technologies Category: Informational Ruiquan Jing Expires: April 22, 2019 China Telecom October 22, 2018 Framework on Customer Premises Equipment Control in Optical Transport Networks draft-zheng-ccamp-cpe-otn-fwk-00 Abstract The term Customer Premises Equipment (CPE) describes the terminals that are associated with a carrier's telecommunication network. The CPE provides access between a customer's devices and the network. This document describes the framework for control of CPEs in optical transport networks. Gap analysis is also included as guidance for potential solutions such as protocol extensions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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. This Internet-Draft will expire on April 22, 2019. Copyright Notice Zheng, et al. Expires April 2019 [Page 1] Internet-Draft CPE Control in OTN October 2018 Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 2 2. CPE Scenarios and Framework .................................. 3 2.1. B2B Leased Line Services in OTN context .................... 3 2.2. CPE Terminology ........................................... 3 3. Requirement Analysis for CPE Control ......................... 4 4. GMPLS Applicability ......................................... 5 5. YANG Model Applicability ..................................... 5 6. Other Control Plane Requirement .............................. 6 7. Network Management .......................................... 6 8. Security Considerations ...................................... 6 9. IANA Considerations ......................................... 6 10. References ................................................. 7 10.1. Normative References ................................... 7 10.2. Informative References ................................. 8 11. Authors' Addresses .......................................... 8 1. Introduction Carriers are providing leased line business-to-business (B2B) services to their customers. These kinds of service have special requests on bandwidth, latency, and other performance features. As the leased line services start at the Customer Premises Equipment (CPEs), the end-to-end (E2E) services need to be coordinated over heterogeneous networks with the support of CPE control mechanisms. The Generalized Multi-Protocol Label Switching (GMPLS) techniques [RFC3945] have been widely applied in metro and backbone network, Zheng Expires April 2019 [Page 2] Internet-Draft CPE Control in OTN October 2018 providing effective deployment and efficient recovery mechanisms. A detailed summary is provided in Section 4 of this document. The YANG models specified by the IETF can also be applied to satisfy the requirement of CPE control. The models' applicability is analyzed in Section 5. This document describes the framework for control of the CPE in optical transport networks. Gap analysis is also included as guidance for potential solutions such as protocol extensions. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. CPE Terminology TBD. 2. CPE Scenarios and Framework This section provides overviews of the GMPLS control plane and centralized controller systems as well as the interactions between the GMPLS control plane and centralized controllers. 2.1. B2B Leased Line Services in OTN context +-------------------------------------------------+ | Carrier Orchestrator System | +---+-----------+----------+------------------+---+ | | | | .......|...........|..........|..................|....... : | | +--------+--------+ | : : | | | CPE Ctrl& Mgmt | | : : +----+----+ +-+--------------+ | +----+----+ : : | EMS/NMS | | CPE Control |--+-+ | EMS/NMS | : : | VendorA | | and Management | | | VendorB | : Zheng Expires April 2019 [Page 3] Internet-Draft CPE Control in OTN October 2018 : +----+----+ +-------+--------+ | +----+----+ : :......|.................|...........|...........|......: | | | | _|_________________|_ _|___________|__ / \ / \ / Vendor A DCN \ / Vendor B DCN \ \ / \ / \_____________________/ \________________/ | | ______|______ ______|______ / \ / \ +---+ | OTN | | OTN | +---+ |CPE|---+ Domain A |-------| Domain B +---|CPE| +---+ | | | | +---+ \_____________/ \_____________/ Figure 1: Architecture for OTN CPE Scenario In the Figure 1, a two-domain example of OTN network is used with CPE devices accessed to respective OTN domains. This architecture is an extension of existing one with controller hierarchies. The dashed line shows a logical of controller that directly controls the OTN domain via DCN. More specifically, besides traditional NMS/EMS, there is another CPE control/Management functional block in the system, to accomplish the control function of CPE devices. This logical system is further connected to carrier orchestration system. 3. Requirement Analysis for CPE Control In order to support the above scenarios, the following functionalities need to be satisfied. Interaction between CPE and NMS/EMS: - Report and Query the basic information from the CPE; - Configuration of CPE and OTN Access; - Management of the Connections/CPEs; Interaction between CPE and OTN Access: - Discovery and mapping to the right OTN access; Zheng Expires April 2019 [Page 4] Internet-Draft CPE Control in OTN October 2018 - Set up of connection between CPE and OTN via access protocol; The above interactions are should be automatically processed rather than manually. The main challenges are the limited resources (storage/memory/computation) on the CPE are not as good as on core nodes, so the solution may be different with core networks. If there are potential different protocols for the CPE, the interworking between the CPE and the core network would also need to be investigated. 4. GMPLS Applicability GMPLS [RFC3945] is capable of three different kind of functionality: discovery, routing, and signaling. The Link Management Protocol (LMP) [RFC4204] runs between a pair of physically or virtually adjacent nodes and is used to manage TE links. In addition to setting up and maintaining control channels, LMP can be used to discover and verify data link connectivity and to correlate the properties of the link. LMP is also applicable to the CPE scenario. Routing protocols, especially OSPF-TE [RFC4203], have been extended to provide link state capabilities for GMPLS. The same characteristics may be used for CPE control. In GMPLS, the signaling function is basically accomplished via RSVP- TE [RFC3473], with the definition of generalized label request and label set. Even if the current solution set is complete, it is challenging in the CPE scenario to support all the functions with limited resources on a simple CPE device. In order to support the automation of control in CPE environments, it is necessary to specify a simplified version of control protocols, to satisfy specific requirements in CPE control. 5. YANG Model Applicability [RFC7895] describes a YANG library that provides information about all the YANG modules used by a network management server. The NETCONF protocol defined in [RFC6241] can be used to support these YANG modules with the XML based data encoding. [RFC7407] defines the usage of YANG data models for the configuration of SNMP engines, which can also be applied for CPE configuration. A set of YANG submodules that share the same Zheng Expires April 2019 [Page 5] Internet-Draft CPE Control in OTN October 2018 namespace have been specified to add configuration support for SNMP features. These submodules include a common session, together with configurations to SNMP engine, target, notification, proxy, community and so on. These functions are required in CPE control, and these submodules can be applied in the system. [RFC8343] defines a YANG data model for the management of network interfaces, including the definitions for configuration and system state (status information and counters for the collection of statistics), satisfying the Network Management Datastore Architecture (NMDA), as a fundamental model. A few interface-type- specific models augment to this model, to support the interface management in tech-specific network scenarios, such as [RFC8344] for IP interfaces and [draft-ietf-netmod-intf-ext-yang] for Ethernet. Other functions have also been modeled in various other documents. Routing functions and DHCP have also been supported in [RFC8349]. [draft-ietf-ccamp-alarm-module] provides a module for alarm management, [draft-ietf-netconf-ssh-client-server] and [draft-ietf- netconf-tls-client-server] specify the usage of communication protocols. Potential gaps in the current set of models for CPE control may include performance monitoring and management, fault diagnosis and management, configuration and collection on device port and so on. These modules need to be covered in future documents for a complete CPE control solution. 6. Other Control Plane Requirement TBD. 7. Network Management TBD. 8. Security Considerations TBD. 9. IANA Considerations TBD. Zheng Expires April 2019 [Page 6] Internet-Draft CPE Control in OTN October 2018 10. References 10.1. Normative References [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC6241] R. Enns, et. al,. Network Configuration Protocol (NETCONF), RFC6241, June 2011. [RFC7407] M. Bjorklund, J. Schoenwaelder, A YANG Data Model for SNMP Configuration, RFC 7407, December 2014. [RFC7895] A. Bierman, et. al,. YANG Module Library, RFC7895, June 2016. [RFC8343] M. Bjorklund, A YANG Data Model for Interface Management, RFC8343, March 2018. [RFC8344] M. Bjorklund, A YANG Data Model for IP Management, RFC8344, March 2018. [RFC8349] L. Lhotka, et. al., A YANG Data Model for Routing Management (NMDA Version), RFC 8349, March 2018. [draft-ietf-netmod-intf-ext-yang] R. Wilton, et. al, Common Interface Extension YANG Data Models, work in progress. [draft-ietf-ccamp-alarm-module] S. Vallin, et. al, YANG Alarm Module, work in progress. [draft-ietf-netconf-ssh-client-server] K. Watson, et. al, YANG Groupings for SSH Clients and SSH Servers, work in progress. Zheng Expires April 2019 [Page 7] Internet-Draft CPE Control in OTN October 2018 [draft-ietf-netconf-tls-client-server] K. Watson, et. al, YANG Groupings for TLS Clients and TLS Servers, work in progress. 10.2. Informative References 11. Authors' Addresses Haomian Zheng Huawei Technologies H1-1-A043S, Huawei Industrial Base, Songshanhu, Dongguan, P.R.China Email: zhenghaomian@huawei.com Ruiquan Jing China Telecom Email: jingrq.bri@chinatelecom.cn Zheng Expires April 2019 [Page 8]