[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

TEAS Working Group                                         X. Zhang, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                 J. Ryoo
Expires: May 4, 2017                                                ETRI
                                                        October 31, 2016


    A Service YANG Model for Connection-oriented Transport Networks
              draft-zhang-teas-transport-service-model-01

Abstract

   A transport network is a server-layer network designed to provide
   connectivity services for a client-layer network to carry the client
   traffic opaquely across the server-layer network resources.  A
   transport network may be constructed from equipments utilizing any of
   a number of different transport technologies such as the evolving
   optical transport infrastructure (Synchronous Optical Networking
   (SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport
   Network (OTN)) or packet transport as epitomized by the MPLS
   Transport Profile (MPLS-TP).

   This draft provides a transport service YANG model that can be used
   together with the RESTCONF protocol for a northbound client to
   initiate service requests toward the transport network controllers
   via the RESTful interface between them so as to enable automated
   service interations.

Requirements Language

   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 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."



Zhang & Ryoo               Expires May 4, 2017                  [Page 1]


Internet-Draft           Transport Service Model            October 2016


   This Internet-Draft will expire on May 4, 2017.

Copyright Notice

   Copyright (c) 2016 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Service Model - YANG Tree . . . . . . . . . . . . . . . . . .   4
   4.  Service Model - YANG Code . . . . . . . . . . . . . . . . . .   6
   5.  General Considerations and Some Open Issues . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  Manageability Considerations  . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  14
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   A transport network is a server-layer network designed to provide
   connectivity services, or more advanced services like Virtual Private
   Networks (VPN) for a client-layer network to carry the client traffic
   opaquely across the server-layer network resources.  It acts as a
   pipe provider for upper-layer networks, such as IP network and mobile
   networks.

   Transport networks, such as Synchronous Optical Networking (SONET) /
   Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN),
   Wavelength Division Multiplexing (WDM), and flexi-grid networks, are
   often built using equipments from a single vendor and are managed
   using private interfaces to dedicated Element Management Systems



Zhang & Ryoo               Expires May 4, 2017                  [Page 2]


Internet-Draft           Transport Service Model            October 2016


   (EMS) / Network Management Systems (NMS).  All transport networks
   have high benchmarks for reliability and operational simplicity.
   This suggests a common, technology-independent management/control
   paradigm that is extended to represent and configure specific
   technology attributes.

   The YANG language [RFC6020] is currently the data modeling language
   of choice within the IETF and has been adopted by a number of
   industry-wide open management and control initiatives.  YANG may be
   used to model both configuration and operational states; it is
   vendor-neutral and supports extensible APIs for control and
   management of elements.

   This document, exploting the YANG language, provides a transport
   service model that can be used by a northbound client (e.g., an
   orchestrator, a client network controller etc.) to initiate service
   requests, as well as retrieving service states, toward the transport
   network via the RESTful interface provided by the transport network
   controller(s).  The model is currently scoped for connection-oriented
   transport networks and connection-less transport networks are out of
   scope.  To understand better what interfaces a service model can
   apply to in the transport SDN architecture (i.e., Abstract Control of
   Transport Networks (ACTN))and how service model relates to other YANG
   models defined in IETF in general, please refer to
   [I-D.zhang-teas-actn-yang]  for more detailed information.

2.  Terminology

   A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in the YANG data tree
   presented later in this draft is defined in
   [I-D.ietf-netmod-rfc6087bis].  They are provided below for reference.

   o  Brackets "[" and "]" enclose list keys.

   o  Abbreviations before data node names: "rw" means configuration
      (read-write) and "ro" state data (read-only).

   o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

   o  Ellipsis ("...") stands for contents of subtrees that are not
      shown.





Zhang & Ryoo               Expires May 4, 2017                  [Page 3]


Internet-Draft           Transport Service Model            October 2016


3.  Service Model - YANG Tree

   The service model YANG tree is provided below:
















































Zhang & Ryoo               Expires May 4, 2017                  [Page 4]


Internet-Draft           Transport Service Model            October 2016


   module: ietf-transport-service
      +--rw transport_service
         +--rw service* [service-name]
            +--rw service-name    -> ../config/service-name
            +--rw config
            |  +--rw service-name?        string
            |  +--rw service-id?          uint32
            |  +--rw service-endpoints* [node-id tp-id]
            |  |  +--rw type?            enumeration
            |  |  +--rw node-id          union
            |  |  +--rw tp-id            uint32
            |  |  +--rw endpoint-name?   string
            |  +--rw service-type         identityref
            |  +--rw supporting-tunnel
            |  |  +--rw tunnel-name?   string
            |  +--rw bandwidth?           decimal64
            |  +--rw protection-type?     identityref
            |  +--rw constraints
            |     +--rw delay-limit?            uint32
            |     +--rw delayvariation-limit?   uint32
            |     +--rw packetloss-limit?       decimal64
            |     +--rw objective?              identityref
            +--ro state
               +--ro service-name?        string
               +--ro service-id?          uint32
               +--ro service-endpoints* [node-id tp-id]
               |  +--ro type?            enumeration
               |  +--ro node-id          union
               |  +--ro tp-id            uint32
               |  +--ro endpoint-name?   string
               +--ro service-type         identityref
               +--ro supporting-tunnel
               |  +--ro tunnel-name?   string
               +--ro bandwidth?           decimal64
               +--ro protection-type?     identityref
               +--ro creation-time?       ytypes:date-and-time
               +--ro constraints
               |  +--ro delay-limit?            uint32
               |  +--ro delayvariation-limit?   uint32
               |  +--ro packetloss-limit?       decimal64
               |  +--ro objective?              identityref
               +--ro performance-info
               |  +--ro delay?             uint32
               |  +--ro delay-variation?   uint32
               |  +--ro packet-loss?       decimal64
               +--ro oper-status          tet:te-oper-status





Zhang & Ryoo               Expires May 4, 2017                  [Page 5]


Internet-Draft           Transport Service Model            October 2016


4.  Service Model - YANG Code



 <CODE BEGINS>file "ietf-transport-service@2016-10-31.yang"
module ietf-transport-service {
        yang-version 1;
        namespace "urn:ietf:params:xml:ns:yang:ietf-transport-service";
        prefix transservice;

        import ietf-inet-types {
                prefix inet;
        }

        import ietf-yang-types {
          prefix ytypes;
        }

        import ietf-te-types {
                prefix "tet";
        }



        organization "Internet Engineering Task Force";
        contact
                "Editor: Xian ZHANG (zhang.xian@huawei.com)";
        description
                "this module describes a service module that is an essential
                API for a client to ask for a provider network for a path
                without the need to care about underlying technologies.
                Capability to specify constraints/policies are provided as
                optional features.";

        revision 2016-10-31 {
                description
                        "Initial revision.";
                        reference "to add the draft name";
        }

        grouping endpoints-grouping{
                description "end point grouping";
                leaf type {
                        type enumeration {
                                enum root {
                                        description "root";
                                }
                                enum leaf {



Zhang & Ryoo               Expires May 4, 2017                  [Page 6]


Internet-Draft           Transport Service Model            October 2016


                                        description "leaf";
                                }
                                enum unknown {
                                        description "unknown";
                                }
                        }
                default root;

                description
                        "This attribute indicates whether a endpoint of the
                        service is acting as a root or leaf, and takes on
                        the value either root, leaf or unkown. If the service
                        type is Point-to-Point or Multipoint-to-Multipoint,
                        then the type is equal to root. If the service type
                        is Point-to-Multipoint, then the type can be either
                        root or leaf.";
                }


                leaf node-id {
                        type union {
                                type inet:ip-address; //IPv4 or IPv6
                                type uint32;
                        }
                        description
                                "the node address of a service .";
                }

                leaf tp-id {
                        type uint32;
                        description
                                "the termination point of a service.";
                }

                leaf endpoint-name {
                        type string;
                        description
                                "the name of this service endpoint";
                }
        }

        identity service-type {
                description
                        "base identity from which the specific service
                        type can be derived.";
        }

        identity service-P2P {



Zhang & Ryoo               Expires May 4, 2017                  [Page 7]


Internet-Draft           Transport Service Model            October 2016


                base service-type;
                description
                        "a point-to-point service type";
        }

        identity service-P2MP {
                base service-type;
                description
                        "a point to multi-point type";
        }

        identity service-MP2MP {
                base service-type;
                description
                        "a multi-point to multi-point type";
        }

//note: service type such as EPL, EVPL, EPLAN
//      EVPLAN, E-Tree can be added when augmenting
//      this model.

        identity service-prot-type {
                description
                        "base identity from which the specific
                         protection type can be derived.";
        }

        identity service-prot-unprotected {
                base service-prot-type;
                description
                        "service protection type: unprotected";
        }

        identity service-prot-1plusR {
                base service-prot-type;
                description
                        "service protection type: dynamic reroute";
                reference
                        "draft-ietf-teas-gmpls-resource-sharing-proc-04";
        }

        identity service-prot-1plus1 {
                base service-prot-type;
                description
                        "service protection type: static 1+1";
        }

        identity service-prot-1plus1plusR {



Zhang & Ryoo               Expires May 4, 2017                  [Page 8]


Internet-Draft           Transport Service Model            October 2016


                base service-prot-type;
                description
                        "service protection type: 1+1+R";
                reference
                        "draft-ietf-teas-gmpls-resource-sharing-proc-04";
        }

        identity objective-type{
                description
                        "base identity from which the specific obective
                        funciton can be derived.";
        }
        identity objective-mindelay{
                base objective-type;
                description
                        "objective: minimized delay";
        }
        identity objective-mincost {
                base objective-type;
                description
                        "objective: minimized cost";
        }

        identity objective-mindistance {
                base objective-type;
                description
                        "objective: minimized distance";
        }

        grouping service-config-grouping {
                description "service-config-groupoing";

                leaf service-name{
                        type string;
                        description "the name for a service";
                }

                leaf service-id {
                        type uint32;
                        description
                                "an unique identificaiton of a service.";
                }

                list service-endpoints{
                        key "node-id tp-id";
                        description
                                "this provides the service endpoints and it can be used
                                to support different types of services (including P2P,



Zhang & Ryoo               Expires May 4, 2017                  [Page 9]


Internet-Draft           Transport Service Model            October 2016


                                MP2MP, P2MP)";

                        uses endpoints-grouping;
                }

                leaf service-type {
                        type identityref {
                                base service-type;
                        }
                        mandatory true;
                        description
                                "the type of a service request";
                }

                container supporting-tunnel {
                        leaf tunnel-name{
                                type string;
                                description "the name of a tunnel (unique)";
                        }

                        description
                                "the tunnels that can be used to support the service";
                }

                leaf bandwidth {
                        type decimal64 {
                                fraction-digits 2;
                        }
                        description "the bandwidth requested by a service.";
                }

                leaf protection-type{
                        type identityref {
                                base service-prot-type;
                        }
                        description
                        "the type of protection expected for this
                        service";
                }
        }

        grouping constraints-grouping {
                leaf delay-limit {
                        type uint32;
                        description
                        "Delay variation in micro-seconds.";
                }




Zhang & Ryoo               Expires May 4, 2017                 [Page 10]


Internet-Draft           Transport Service Model            October 2016


                leaf delayvariation-limit {
                        type uint32;
                        description
                        "Delay variation.";
                }

                leaf packetloss-limit {
                        type decimal64 {
                                fraction-digits 6;
                                range "0 .. 50.331642";
                        }
                        description
                        "Delay variation in %.";
                }
                leaf objective {
                        type identityref
                        {
                                base objective-type;
                        }
                        description
                                "objective function imposed for path computation
                                from this service.";
                }
                description "constraints gropuing";
        }

        container transport_service {
                description
                        "serves as a top-level container for a list of services";

                list service {
                        key "service-name";
                        description
                                "an unique identifier of a service";

                        leaf service-name {
                                type leafref {
                                        path "../config/service-name";
                                }
                                description "a unique service identifier.";
                        }
                        container config{
                                description "service config container";

                                uses service-config-grouping;

                                container constraints{
                                        uses constraints-grouping;



Zhang & Ryoo               Expires May 4, 2017                 [Page 11]


Internet-Draft           Transport Service Model            October 2016


                                        description
                                                "specify the constraints imposed by a
                                                service";
                                }
                        }

                        container state
                        {
                                config false;
                                description "operational state of a service";

                                uses service-config-grouping;

                                leaf creation-time {
                                        type ytypes:date-and-time;
                                        description
                                                "the time when service is created";
                                }

                                container constraints{
                                        uses constraints-grouping;
                                        description
                                                "specify the constraints imposed by a
                                                service";
                                }

                                container performance-info{
                                        description "service state-performance info";
                                        leaf delay{
                                                type uint32;
                                                description "the latency of this service";
                                        }

                                        leaf delay-variation {
                                                type uint32;
                                                description "the service delay varation";
                                        }
                                        leaf packet-loss {
                                                type decimal64 {
                                                        fraction-digits 6;
                                                        range "0 .. 50.331642";
                                                }
                                                description "packet loss";
                                        }
                                }
                                leaf oper-status {
                                        type tet:te-oper-status;
                                        mandatory true;



Zhang & Ryoo               Expires May 4, 2017                 [Page 12]


Internet-Draft           Transport Service Model            October 2016


                                        description
                                                "the operational status of this service";
                                }
                        }//end of state of a service
                }//end of service list (including config and state)
        }//service top container
}


<CODE ENDS>



5.  General Considerations and Some Open Issues

   [I-D.liu-netmod-yang-schedule] defines a YANG data model for
   configuration scheduling.  A service model can also be scheduled,
   therefore the ietf-schedule model can be used to serve this purpose
   by specifying the appropriate object using xpath.

   Functions that are under considerations for updating the YANG model:

      1): Service delivery model augmentation: Information such as PIR/
      CIR pertaining to ETH service is needed and it is more appropriate
      to augment the base model; for OTN-based service model, signal-
      type information needs to be added;

      2): To add service-related notification, e.g.: service up; service
      down, service degraded etc.; Currently, there are two options
      available, one is using the method provided in [RFC5277], the
      other one is using the new mechanism proposed in
      [I-D.ietf-netconf-yang-push].

      3): To figure out how to deal with attributes such as bandwidth,
      schedule where it can be per node for non-P2P, but is per node
      pair for P2P;

      4): to add XRO/IRO constraints;

6.  IANA Considerations

   TBD.

7.  Manageability Considerations

   TBD





Zhang & Ryoo               Expires May 4, 2017                 [Page 13]


Internet-Draft           Transport Service Model            October 2016


8.  Security Considerations

   Since the data model defined in this draft is manipulated via, for
   example, the interface between an orchestrator and a transport
   network controller.  The YANG module defined in this draft is
   designed to be accessed via the RESTCONF protocol defined in
   [I-D.ietf-netconf-restconf], or maybe via the NETCONF protocol
   [RFC6241].  As mentioned in Security Conserations Section of
   [I-D.ietf-netconf-restconf] that HTTPS defined in [RFC7230] can be
   used to provide security while accessing data.

   There are a number of data nodes defined in the YANG module which are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., POST) to these
   data nodes without proper protection can have a negative effect on
   network operations.

   Editor note: to List specific subtrees and data nodes and their
   sensitivity/vulnerability.

9.  Acknowledgements

   We would like to thank Baoquan Rao and Gang Xie for their initial
   discussions that trigger the generation of this draft.  We would also
   like to thank Michael Scharf from Nokia for very useful comments to
   this draft and the model.

   Aspects of the work in this Internet-Draft is funded by the UK
   Engineering and Physical Sciences Research Council (EPSRC) under the
   TOUCAN project (EP/L020009/1).

10.  Contributors

   Zhe Liu
   Huawei Technologies
   Email: liuzhe123@huawei.com

   Sergio Belotti
   Nokia
   Email:sergio.belotti@nokia.com

   Daniel King
   Lancaster University
   Email:d.kindg@lancaster.ac.uk






Zhang & Ryoo               Expires May 4, 2017                 [Page 14]


Internet-Draft           Transport Service Model            October 2016


11.  References

11.1.  Normative References

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-13 (work in
              progress), April 2016.

   [I-D.ietf-netmod-rfc6087bis]
              Bierman, A., "Guidelines for Authors and Reviewers of YANG
              Data Model Documents", draft-ietf-netmod-rfc6087bis-06
              (work in progress), March 2016.

   [I-D.liu-netmod-yang-schedule]
              Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
              O. Dios, "A YANG Data Model for Configuration Scheduling",
              draft-liu-netmod-yang-schedule-02 (work in progress),
              October 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

11.2.  Informative References

   [I-D.ietf-netconf-yang-push]
              Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
              Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to
              YANG datastore push updates", draft-ietf-netconf-yang-
              push-04 (work in progress), October 2016.

   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., Chen,
              X., Jones, R., and B. Wen, "A YANG Data Model for Traffic
              Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
              te-03 (work in progress), March 2016.



Zhang & Ryoo               Expires May 4, 2017                 [Page 15]


Internet-Draft           Transport Service Model            October 2016


   [I-D.zhang-teas-actn-yang]
              Lee, Y., Zhang, X., Yoon, B., Dios, O., and J. Shin,
              "Applicability of YANG models for Abstraction and Control
              of Traffic Engineered Networks", draft-zhang-teas-actn-
              yang-02 (work in progress), October 2016.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
              <http://www.rfc-editor.org/info/rfc5277>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

Authors' Addresses

   Xian Zhang (editor)
   Huawei Technologies
   F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P.R.China

   Email: zhang.xian@huawei.com


   Jeong-dong Ryoo
   ETRI

   Email: ryoo@etri.re.kr





















Zhang & Ryoo               Expires May 4, 2017                 [Page 16]


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