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

Versions: 00 01 02 03 04 05 06

SDNRG                                                           X. Li
Internet Draft                                                Y. Zhou
Intended status: Informational                                   BUPT
Expires: October 2019                                         D. Wang
                                                              Z. Wang
                                                              J. Wang
                                                                  ZTE
                                                                W. Li
                                                               S. Yin
                                                             S. Huang
                                                                 BUPT
                                                       April 05, 2019



       Path Table based Routing Mechanism in Software-Defined Optical
                        Transport Networks (SD-OTN)
              draft-li-sdnrg-path-table-routing-in-sd-otn-06


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), 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 October 05, 2019.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.





Li, et al.            Expires October 05, 2019               [Page 1]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


   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.

Abstract

   The dynamic establishment and removal of an end-to-end light-path
   consume a lot of time which are also the main burden of control plane
   in optical transport networks. With the frequent arrival and
   departure of services, the control plane needs to handle a large
   number of control and management messages to conduct path
   computation, resource reservation and cross connection configuration.
   This draft proposes a novel routing mechanism based on Path Table for
   software-defined optical transport networks (SD-OTN). The Path Table
   reserves partial activated established light-paths that can be
   directly used by subsequent requests for subsequent services. This
   new routing mechanism can reduce the network load and save routing
   time for some services.

Table of Contents


   1. Introduction ................................................ 3
   2. Conventions used in this document ........................... 3
   3. Motivation of Path Table based Routing Mechanism ............ 4
   4. Path Table based Routing Architecture ....................... 4
      4.1. Architecture ........................................... 5
      4.2. Path Table ............................................. 5
      4.3. Matching ............................................... 7
      4.4. Table-miss ............................................. 8
      4.5. Path Removal ........................................... 8
      4.6. Counters ............................................... 8
      4.7. Instructions ........................................... 9
   5. Security Considerations .................................... 10
   6. IANA Considerations ........................................ 10
   7. References ................................................. 10
      7.1. Normative References .................................. 10
   8. Acknowledgments ............................................ 10








Li, et al.            Expires October 05, 2019               [Page 2]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


1. Introduction

   This document describes the principle of Path Table based routing
   mechanism for software-defined optical transport networking (SD-OTN).
   With the development of bandwidth intensive applications such as
   cloud services, high definition, social networking, big data, etc.,
   optical transport networks which take the advantage of high-capacity
   and low propagation delay become an important infrastructure for data
   transmission. The optical transport networks need to dynamically
   establish end-to-end light-path for each service. The established
   end-to-end light-path is used to transfer data for a period of time
   in the optical transport networks. The dynamic establishment and
   removal of an end-to-end light-path is implemented by control plane.
   The traditional control plane adopts GMPLS protocol which is composed
   of OSPF module, LRM module, RSVP module, PCE module, etc. The OSPF
   module or PCE module conducts path computation and RSVP module
   realizes resource reservation. Recently, the software defined network
   (SDN) which takes advantage of centralized control is proposed. In
   SDN architecture, the control plane is extracted from the data plane
   and realized in a centralized controller. The controller communicates
   with data plane through multiple protocols such as OpenFlow and PCEP.
   SDN is now being applied to the optical transport networks using
   ROADMs and multiple modulation levels programmable transponders. SDN-
   enabled optical transport networks are called software-defined
   optical transport network (SD-OTN),  which is expected to be more
   open, programmable, and application aware. In SDON, the establishment
   and removal of an end-to-end light-path is implemented by the
   centralized controller. When one request arrives, the controller will
   compute the path and distribute the cross connection message by
   southbound protocol for optical transport networks. The dynamic
   establishment and removal of an end-to-end light-path consumes a lot
   of time and increases the control and managing burden on optical
   transport network. This draft proposes a novel Path Table based
   routing mechanism for software-defined optical transport networks
   (SD-OTN). The Path Table reserves partial activated established
   light-paths that can be used by subsequent requests for subsequent
   services. If a subsequent service matches a light-path entry in the
   Path Table, the controller does not need to establish a new end-to-
   end light-path for this request and only assign the existing light-
   path to this request for data transmission. This new routing
   mechanism can reduce the network load and save a lot of path
   computation time for some services.
2. Conventions used in this document

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


Li, et al.            Expires October 05, 2019               [Page 3]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


   The following acronyms are used in this document.

   SDN: Software-Defined Networking

   SDON: Software-Defined Optical Networks

   GMPLS: Generalized Multi-Protocol Label Switching

   PCE: Path Calculation Element

   RSVP: Resource Reservation Protocol

   OSPF: Open Shortest Path First

   TED: Traffic Engineering Database

   ROADM: Reconfigurable Optical Add and Drop Multiplexer

3. Motivation of Path Table based Routing Mechanism

   The traffic requests arrive and depart from the network dynamically
   in a random manner. When a request arrives, the control plane must
   immediately find a light-path available for the traffic demand. With
   the frequent arrival and departure of service requests, the optical
   transport networks need to dynamically establish and remove the end-
   to-end light-path for each service request. The establishment and
   removal of end-to-end light-path not only consume much time but also
   will occupy the bandwidth of management channel. The software module
   in the controller and optical devices need to produce and handle too
   many messages to conduct path calculation and cross connection
   configuration. In view of the flow table used at each OpenFlow-
   enabled switch, we propose the Path Table for SD-OTN. Path Table
   preserves the existing established light-paths which are not used by
   any request currently. Taking advantage of Path Table, the controller
   will first search the suitable light-path in the Path Table for each
   request. If there exist one suitable light-path matching the current
   request, the controller assigns the matched light-path to this
   request. Otherwise, the controller will establish one end-to-end
   light-path for this request. From the perspective of time statistical
   point of traffics, the Path Table will get enormous benefits.

4. Path Table based Routing Architecture

   This section first gives an overview of the architecture of Path
   Table based routing model.




Li, et al.            Expires October 05, 2019                 [Page 4]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


4.1. Architecture

   Figure 1 below shows the component of a centralized controller with
   PCE.  PCE is a special computational component which can support
   large, multi-domain, multi-region and multi-layer network constrain-
   based path computation. The OpenFlow protocol is used to exchange
   message between optical devices and controller. Service requests of
   provisioning end-to-end light-path are received by the controller.
   The controller will transmit the request to the PCE modular. The PCE
   modular operates on the Path Table and TED to respond with the
   requested path.

                +-----------------------------------+
                |    +-------+          Controller  |
                |    |  TED  |                      |
                |    +-------+                      |
                |      A   |                        |
                |      |   |                        |
                |      |   V                        |
                |    +-------+ <-- +------------+   |
                |    |  PCE  |     | Path Table |   |
                |    +-------+ --> +------------+   |
                |                       A   |       |
                |                       |   |       |
                |                       |   V       |
                +---------------------------------- +
                |                SAL                |
                +-----------------------------------+
                  A     |
                  |     | Southbound Protocol
                  |     |
                  |     V
                +---------+    +---------+    +---------+
                |  ROADM  |--->|  ROADM  |--->|  ROADM  |
                +---------+    +---------+    +---------+

              Figure 1 Path table based routing architecture



4.2. Path Table

   The Path Table consists of a lot of path entries. Each path entry
   represents one already established light-path in the SD-OTN and is
   identified by its source-destination node and bandwidth.




Li, et al.            Expires October 05, 2019                [Page 5]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


   +----------------------------+----------------------------------+
   |           Match Fields     |        |        |       |        |
   +------+-----------+---------+Priority|Counters|Instru-|Timeouts|
   |Source|Destination|Bandwidth|        |        |ctions |        |
   +------+-----------+---------+--------+--------+-------+--------+
   |   A  |     B     |   40G   |    0   |    0   |   0   |    0   |
   +------+-----------+---------+--------+--------+-------+--------+
   |   C  |     D     |   100G  |    0   |    0   |   0   |    0   |
   +------+-----------+---------+--------+--------+-------+--------+

                          Table 1 Path table



   Each path entry (as presented in Table 1) contains:

   Match Fields: match the service requests. It consists of the source
   node, destination node and bandwidth.

   Source: the node at which the traffic uploads.

   Destination: the node at which the traffic downloads.

   Bandwidth: the assigned spectrum or wavelengths for the service
   request.

   Priority: matching precedence of the path entry.

   Counters: updated when requests are matched.

   Instructions: to send the request to next table or assign the matched
   light-path to this request.

   Timeouts: maximum amount of time or idle time before path is expired
   by the controller.













Li, et al.            Expires October 05, 2019               [Page 6]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


4.3. Matching

           +---------+
           | Request |
           +---------+
                | <-------------------------------------+
                V                                       | Yes
              /   \                                     |
             /Match\            +---------------+      /  \
            /in Tab-\    Yes    |Update counters|     /Goto\
            \ ble n / --------->|   Excute      |--> / Table\
             \  ?  /            | instructions  |    \  n ? /
              \   /             +---------------+     \    /
                | No                    A              \  /
                V                       |                |
              /   \                     |                | No
             /     \                    |                V
            /Table- \   Yes             |       +------------------+
           /miss Path\ -----------------+       |Execute action set|
           \  entry  /                          +------------------+
            \ exist?/
             \     /
              \   /
                |
                V
           +-----------+
           |Reject this|
           |  request  |
           +-----------+

       Figure 2 Flowchart detailed request flow through in controller



   Once a request arrives, the controller performs the functions as
   shown in Figure 2. The controller starts with performing a table
   lookup in the first path table and may perform table lookups in other
   path tables. The source node, destination node and bandwidth are
   extracted from the request. Light-path match fields used for table
   lookups depend on the request's source-destination and bandwidth.

    A request matches a path table entry if the source node, destination
   node and bandwidth all match fields used for the lookup match those
   defined in the path table entry. If a path table entry field has a
   value of ANY (field omitted), it matches all possible values. The
   request is matched with the path table and only the highest priority
   light-path entry that matches the request must be selected. The


Li, et al.            Expires October 05, 2019               [Page 7]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


   counters associated with the selected path entry must be updated and
   the action included in the selected path entry must be carried out.
   If there are multiple matched light-path entries with the same
   highest priority, the selected light-path entry is explicitly
   undefined.

4.4. Table-miss

   Every path table must support a table-miss light-path entry to
   process table misses. The table-miss flow entry specifies how to
   process requests unmatched by other light-path entries in the path
   table, may send the request to PCE or other controller. The table-
   miss light-path entry is identified by its match and its priority, it
   wildcards all match fields and has the lowest priority. The match of
   the table-miss light-path entry must support sending the request to
   the PCE. It also may support sending the request to the other
   controller. The table-miss path entry behaves in the same way as any
   other path entry, but it does exist by default in each path table.

4.5. Path Removal

   Path entries are removed from path table in two ways, either via the
   controller, or the light-path (path entry) expiry mechanism.

   The path expiry mechanism is run dependently in the controller and it
   is based on the state and configuration of path entries. Each path
   entry has an idle timeout and a hard timeout associated it. If the
   hard timeout field is non-zero, the controller must note the path
   entry's arrival time, at it may need to evict the entry later. A non-
   zero hard timeout field causes the path entry to be removed after the
   given number of seconds, regardless of how many requests it has
   matched. A non-zero idle timeout field causes the path entry to be
   removed when it has matched no paths in the given number of seconds.
   The controller must implement path expiry and remove path entries
   from the path table when one of their timeouts is exceeded.

   The controller may actively remove path entries from path table. Path
   entries may be removed from path tables when controller needs to
   reclaim resources. The controller selects the removed path depending
   on path entry parameters, resource mapping in the controller and
   other internal controller constraints.

4.6. Counters






Li, et al.            Expires October 05, 2019              [Page 8]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


   Counters are maintained for each path table and path entry. Counters
   may be implemented in software and maintained by polling hardware
   counters with more limited ranges. Table 2 contains the set of
   counters defined by our suggestions. A controller is not required to
   support all counters, just those marked "required" in Table 2.
   Duration refers to the amount of time the path entry has been
   installed in the controller.

   +---------------------------------+-------------+-------------+
   |           Counter               |     Bits    |             |
   +---------------------------------+-------------+-------------+
   |                        Per Flow Entry                       |
   +---------------------------------+-------------+-------------+
   |Reference Count (active entries) |      32     |  Required   |
   +---------------------------------+-------------+-------------+
   |           Path Lookups          |      64     |  Optional   |
   +---------------------------------+-------------+-------------+
   |           Path Matches          |      64     |  Optional   |
   +---------------------------------+-------------+-------------+
   |                        Per Path Entry                       |
   +---------------------------------+-------------+-------------+
   |         Received requests       |      64     |  Optional   |
   +---------------------------------+-------------+-------------+
   |         Duration (seconds)      |      32     |  Optional   |
   +---------------------------------+-------------+-------------+
   |       Duration (nanoseconds)    |      32     |  Optional   |
   +---------------------------------+-------------+-------------+

                          Table 2 List of counters



4.7. Instructions

   Each path entry contains a set of instructions which are executed
   when a request matches the entry. A controller is not required to
   support all instruction types, just those marked "Required
   Instruction" below.

   Optional Instruction: send the request to other controller.

   Required Instruction: assign the matched light-path to this request.

   Required Instruction: transmit this request to PCE

   The instruction set associated with a path entry contains a maximum
   of one instruction of each type.


Li, et al.            Expires October 05, 2019              [Page 9]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019

5. Security Considerations

   TBD

6. IANA Considerations

   This document makes no request of IANA.

7. References

7.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

8. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.






























Li, et al.            Expires October 05, 2019              [Page 10]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019

Authors' Addresses

   Xin Li
   Beijing University of Posts and Telecommunications

   Email: xinli@bupt.edu.cn


   Yu Zhou
   Beijing University of Posts and Telecommunications

   Email: shaxiaoziningyi@bupt.edu.cn


   Dajiang Wang
   ZTE Corporation

   Email: wang.dajiang@zte.com.cn


   Zhenyu Wang
   ZTE Corporation

   Email: wang.zhenyu1@zte.com.cn


   Jiayu Wang
   ZTE Corporation

   Email: wang.jiayu1@zte.com.cn


   Wenzhe Li
   Beijing University of Posts and Telecommunications

   Email: lwz@bupt.edu.cn


   Shan Yin
   Beijing University of Posts and Telecommunications

   Email: yinshan@bupt.edu.cn







Li, et al.            Expires October 05, 2019              [Page 11]


Internet-Draft  Path Table based Routing Mechanism in SD-OTN April 2019


   Shanguo Huang
   Beijing University of Posts and Telecommunications

   Email: shghuang@bupt.edu.cn












































Li, et al.            Expires October 05, 2019              [Page 12]


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