[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/