Network Working Group X. Chen Internet-Draft S. Zhuang Intended status: Informational Huawei Expires: April 21, 2016 October 19, 2015 Considerations on Layered Network Tunnel Service Model draft-chen-opswg-nettunnel-model-considerations-00 Abstract Tunnel is one typical service provided by carrier IP network. Network Tunnel service model can provide the northbound interface of network-level tunnel service of the controller to try to simplify the Tunnel provision without involving too much details of Tunnel implementation on the device. This document gives exploratory description about the requirement of network-level Tunnel service and how to define the data model which will provide the guidance for the future definition of the concrete data model. 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 RFC 2119 [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." This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Chen & Zhuang Expires April 21, 2016 [Page 1] Internet-Draft Considerations on Network Tunnel Model October 2015 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. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Consideration of Tunnel Service Model . . . . . . . . . . . . 3 4. Network Tunnel Service Model . . . . . . . . . . . . . . . . 4 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Design of Data Model . . . . . . . . . . . . . . . . . . 5 5. Network MPLS TE Tunnel Service Model . . . . . . . . . . . . 5 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Design of Data Model . . . . . . . . . . . . . . . . . . 6 6. Network IP Tunnel Service Model . . . . . . . . . . . . . . . 7 7. Pre-configuration and Operational Data . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. References . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Tunnel is one typical service provided by carrier IP network. The network tunnel service model is defined to satisfy the common requirement of most tunnel services. It's convenient for the operators to set up the tunnel which serves for the network applications without caring about the details of different types of tunnels which are eventually setup in the network device. The generic properties of the different tunnels and the properties which the network-level tunnels need such as source address of the tunnel are defined and such service model is referred to as network tunnel service model. Some tunnels can support traffic engineering such as bandwidth assurance, setting up the tunnel according to the explicit path which is specified by the user. The generic traffic engineering properties are defined for the network-level applications and such service model Chen & Zhuang Expires April 21, 2016 [Page 2] Internet-Draft Considerations on Network Tunnel Model October 2015 is referred to as network MPLS TE tunnel service model. This service model is based on the network tunnel service model. This document introduces the description of northbound interface of network-level tunnel service and give the pseudo data model tree to explain the idea. 2. Scope The network tunnel service model is defined to satisfy the common requirement of most tunnel services. The network tunnel service defined here is only based on Layer 3 topology and called L3 tunnel. The tunnel will be used for carrying VPN service and the tunnel used for IPv6 transition is not within the scope. Currently the northbound interface of network tunnel service only includes the point-to-point tunnel and in the future the model would include point-to-multipoint and multipoint-to-multipoint tunnel to support the multicast service. The controller will process the network tunnel service model and finally notify the network device to create the tunnel. The configured network tunnels on the controller includes mainly IP tunnel and MPLS TE tunnel. The LDP and SR-BE path which are able to be created on network device can carry VPN service too. But such tunnels are automatically set up according to the route and are not necessary to set up by controller. 3. Consideration of Tunnel Service Model The network tunnel service model is defined to satisfy the common requirement of most tunnel services. It's convenient for the operators to set up the tunnel which serves for the network applications without caring about the details of different types of tunnels which are eventually setup in the network device. Now there are several device-level data models about tunnel are proposed in IETF. I-D.zheng-intarea-gre-yang [I-D.zheng-intarea-gre-yang] defines the data model of GRE tunnel. I-D.liu-rtgwg-ipipv4-tunnel- yang [I-D.liu-rtgwg-ipipv4-tunnel-yang] defines the data model of IP in IP tunnel. I-D.tran-ipecme-yang-ipsec [I-D.tran-ipecme-yang-ipsec] defines the data model of IPsec tunnel. I-D.ietf-teas-yang-te [I-D.ietf-teas-yang-te] defines the data model of MPLS RSVP-TE tunnel. Different types of tunnels have specific tunnel attributes and there are some generic attributes all of these tunnels possess. The operators are normally interested in these common attributes. The generic network tunnel data model is made up of these common properties and the properties which the network-level tunnels need like source address of the tunnel. Chen & Zhuang Expires April 21, 2016 [Page 3] Internet-Draft Considerations on Network Tunnel Model October 2015 In case of MPLS TE tunnel service the services of traffic engineering include bandwidth assurance, setting up the tunnel according to the explicit path which is specified by the user etc. The generic traffic engineering properties are configured for the network-level applications and the tunnel services which support traffic engineering can be provided, There is the requirement of global reoptimization of the network-level tunnels which means the network usability can be increased by computing the new path for all the tunnels and rebuilding the tunnels. Therefore the data model should define the actions used by operator to trigger the progress of global reoptimization. such data model is referred to as network MPLS TE tunnel data model. This data model is based on the network tunnel data model. In case of IP tunnel service the common attributes has been defined in network tunnel data model. If there are other generic specific attributes for IP tunnel and how to define the generic network IP tunnel data model should be discussed. The relationship of the network tunnel data model, network MPLS TE tunnel data model, network IP tunnel data model is shown in the following figure: +---------------------+ | network tunnel | o: augment +---------------------+ o o / \ / \ +------------------------+ +-------------------+ | network MPLS TE tunnel | | network IP tunnel | +------------------------+ +-------------------+ Figure 1: Relationship of Network Tunnel Service Model, Network MPLS TE Tunnel Model, Network IP Tunnel Model 4. Network Tunnel Service Model 4.1. Overview When the operators use the tunnel service they normally only indicate the addresses of both network devices to set up the tunnel. They don't care about the specific tunnel technology. The controller has internal or preconfigured policy to choose the proper specific tunnel technology. The users may consider the tunnel is unidirectional or bidirectional or the tunnel is IP tunnel or MPLS TE tunnel. If they don't configure the controller creates unidirectional tunnel and the MPLS TE tunnel by default. The default policy is implementation- specific. Chen & Zhuang Expires April 21, 2016 [Page 4] Internet-Draft Considerations on Network Tunnel Model October 2015 The network tunnel data model is provided to users to customize their requirement for tunnel services on the controller. 4.2. Design of Data Model The configuration of network tunnel service model should include: the tunnel name, the source and destination addresses, the type of tunnel which indicates the tunnel is IP or MPLS TE, the direction indicator of the tunnel which defines the tunnel is unidirectional or bidirectional. The user can control the state of the tunnel by manually to set the tunnel down . Different tunnel with the different tunnel name can have the same pair of source and destination addresses. Following is a simplified tree representation of the data model for generic network tunnel service configuration. +--rw network-tunnel +--rw p2p-network-tunnels +--rw tunnel* [tunnel-name] +--rw tunnel-name +--rw tunnel-type +--rw direction +--rw admin-status? +--rw source +--rw destination 5. Network MPLS TE Tunnel Service Model 5.1. Overview The operators often configure the following traffic engineering attributes: bandwidth, the explicit-path, priority, color, protection and different TE technology can support the common attributes. The generic traffic engineering properties are configured for the network-level applications by the network MPLS TE tunnel data model on the controller. The network-level tunnel services configured on the controller are supported by RSVP-TE tunnel, Segment-Routing TE tunnel, static TE tunnel created on network device. The requirement of global reoptimization of the network-level tunnels is the network usability can be increased by computing the new path for all the tunnels and rebuilding the tunnels. Sometimes the operators require the reoptimization to specific tunnel. Therefore the data model should define the actions used by operator to trigger the progress of reoptimization. Chen & Zhuang Expires April 21, 2016 [Page 5] Internet-Draft Considerations on Network Tunnel Model October 2015 The network MPLS TE tunnel data model is based on the network tunnel data model. 5.2. Design of Data Model The configuration of network tunnel service model should include: bandwidth of the tunnel, the explicit path which is made up of one or more hops, priority where the tunnel the higher priority can be setup and hold than lower priority, color which is defined by affinity, if the end-to-end hotstandby protection is needed. The rpc defines the global reoptimization and the reoptimization of the specific tunnel. Following is a simplified graphical representation of the data model for generic MPLS TE tunnel service configuration. module: network-te-tunnel augment /network-tunnel/p2p-network-tunnels/tunnel: +--rw te-tunnel-constraints +--rw bandwidth? +--rw priority? +--rw affinities? +--rw path-constraint? | +--rw hop list? | +--rw hop-limit? +--rw hotstandby? +--rw affinities? +--rw path-constraint? +--rw hop list? +--rw hop-limit? Following is a simplified graphical representation of the data model for generic MPLS TE tunnel service rpc. module: network-te-tunnel augment /network-tunnel/p2p-network-tunnels/tunnel: +---x reoptimization | +--ro input | +--ro if-reoptimization +---x reoptimization-by-tunnel | +--ro input | +--ro tunnel-name Chen & Zhuang Expires April 21, 2016 [Page 6] Internet-Draft Considerations on Network Tunnel Model October 2015 6. Network IP Tunnel Service Model The common attributes for IP tunnel service have been defined in network tunnel data model. After the controller processes and converts the network tunnel data model the controller can notify the network device to create one specific type of IP tunnel. It's not necessary for the operator to care about the details of different types of IP tunnels which are eventually setup in the network device. But if the operator would like to specify the more attributes of IP tunnel by the northbound interface the network IP tunnel data model is needed to be defined through augment of Network Tunnel Service Model. The different IP tunnel technology can be applied in different application scenario such as MPLS in UDP used for load balance, GRE used for load balance or security, IPsec used for security. Even for the same usage of load balance, MPLS in UDP and GRE will adopt different implementation parameters. Thus the IP tunnel attributes to satisfy different uses are hard to be unified and maybe all IP tunnel specific attributes have to be defined in the service model which will deviate the rules of definition of service models. There should be further discussion. 7. Pre-configuration and Operational Data This document focuses on the design of the data model of the service configuration which the business users care about. Actually system administrators have to configure the pre-configuration data to help the controller convert the network service configuration to the device-level configuration. The typical of pre-configuration of network Tunnel service models may provide the policy of the models conversion and the resources used for conversion. For example the network MPLS TE tunnel model can be implemented by RSVP-TE tunnel, SR-TE tunnel, static CR-LSP. The pre-configuration can define the policy to select the implementation mode for specific Network TE Tunnel service model. On the other hand, when implement the network TE Tunnel model with RSVP-TE tunnel, the tunnel ID of RSVP-TE tunnel needs to be allocated dynamically by the controller. The pre- configuration can define the resource pool of tunnel ID for allocation. It's challenging to define the operational data of network service data model because the normal users and the system administrators have different perspective. The business users maybe care only about the limited maintenance information but the system administrators need to know more details. For network MPLS TE tunnel model the state and the path information of the tunnel maybe sufficient to the business users but system administrators maybe need to know the type, Chen & Zhuang Expires April 21, 2016 [Page 7] Internet-Draft Considerations on Network Tunnel Model October 2015 tunnel identifier and specific attributes of the tunnel. There should be further discussion. 8. IANA Considerations This document makes no request of IANA. 9. Security Considerations This document does not introduce new security threat. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 10.2. References [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-01 (work in progress), October 2015. [I-D.liu-rtgwg-ipipv4-tunnel-yang] Liu, Y. and A. Foldes, "Yang Data Model for IPIPv4 Tunnel", draft-liu-rtgwg-ipipv4-tunnel-yang-01 (work in progress), July 2015. [I-D.tran-ipecme-yang-ipsec] Tran, K., "Yang Data Model for Internet Protocol Security (IPSec)", draft-tran-ipecme-yang-ipsec-00 (work in progress), May 2015. [I-D.zheng-intarea-gre-yang] Zheng, L., Pignataro, C., Penno, R., and Z. Wang, "Yang Data Model for Generic Routing Encapsulation (GRE)", draft-zheng-intarea-gre-yang-00 (work in progress), July 2015. Chen & Zhuang Expires April 21, 2016 [Page 8] Internet-Draft Considerations on Network Tunnel Model October 2015 Authors' Addresses Xia Chen Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jescia.chenxia@huawei.com Shunwan Zhuang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Chen & Zhuang Expires April 21, 2016 [Page 9]