idnits 2.17.1 draft-li-sdnrg-path-table-routing-in-sd-otn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 08, 2017) is 2389 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SDNRG X. Li 2 Internet Draft Y. Zhou 3 Intended status: Informational BUPT 4 Expires: April 2018 D. Wang 5 Z. Wang 6 J. Wang 7 ZTE 8 W. Li 9 S. Yin 10 S. Huang 11 BUPT 12 October 08, 2017 14 Path Table based Routing Mechanism in Software-Defined Optical 15 Transport Networks (SD-OTN) 16 draft-li-sdnrg-path-table-routing-in-sd-otn-03 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 08, 2018. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 The dynamic establishment and removal of an end-to-end light-path 55 consume a lot of time which are also the main burden of control plane 56 in optical transport networks. With the frequent arrival and 57 departure of services, the control plane needs to handle a large 58 number of control and management messages to conduct path 59 computation, resource reservation and cross connection configuration. 60 This draft proposes a novel routing mechanism based on Path Table for 61 software-defined optical transport networks (SD-OTN). The Path Table 62 reserves partial activated established light-paths that can be 63 directly used by subsequent requests for subsequent services. This 64 new routing mechanism can reduce the network load and save routing 65 time for some services. 67 Table of Contents 69 1. Introduction ................................................ 3 70 2. Conventions used in this document ........................... 3 71 3. Motivation of Path Table based Routing Mechanism ............ 4 72 4. Path Table based Routing Architecture ....................... 4 73 4.1. Architecture ........................................... 5 74 4.2. Path Table ............................................. 5 75 4.3. Matching ............................................... 7 76 4.4. Table-miss ............................................. 8 77 4.5. Path Removal ........................................... 8 78 4.6. Counters ............................................... 8 79 4.7. Instructions ........................................... 9 80 5. Security Considerations .................................... 10 81 6. IANA Considerations ........................................ 10 82 7. References ................................................. 10 83 7.1. Normative References .................................. 10 84 8. Acknowledgments ............................................ 10 86 1. Introduction 88 This document describes the principle of Path Table based routing 89 mechanism for software-defined optical transport networking (SD-OTN). 90 With the development of bandwidth intensive applications such as 91 cloud services, high definition, social networking, big data, etc., 92 optical transport networks which take the advantage of high-capacity 93 and low propagation delay become an important infrastructure for data 94 transmission. The optical transport networks need to dynamically 95 establish end-to-end light-path for each service. The established 96 end-to-end light-path is used to transfer data for a period of time 97 in the optical transport networks. The dynamic establishment and 98 removal of an end-to-end light-path is implemented by control plane. 99 The traditional control plane adopts GMPLS protocol which is composed 100 of OSPF module, LRM module, RSVP module, PCE module, etc. The OSPF 101 module or PCE module conducts path computation and RSVP module 102 realizes resource reservation. Recently, the software defined network 103 (SDN) which takes advantage of centralized control is proposed. In 104 SDN architecture, the control plane is extracted from the data plane 105 and realized in a centralized controller. The controller communicates 106 with data plane through multiple protocols such as OpenFlow and PCEP. 107 SDN is now being applied to the optical transport networks using 108 ROADMs and multiple modulation levels programmable transponders. SDN- 109 enabled optical transport networks are called software-defined 110 optical transport network (SD-OTN), which is expected to be more 111 open, programmable, and application aware. In SDON, the establishment 112 and removal of an end-to-end light-path is implemented by the 113 centralized controller. When one request arrives, the controller will 114 compute the path and distribute the cross connection message by 115 southbound protocol for optical transport networks. The dynamic 116 establishment and removal of an end-to-end light-path consumes a lot 117 of time and increases the control and managing burden on optical 118 transport network. This draft proposes a novel Path Table based 119 routing mechanism for software-defined optical transport networks 120 (SD-OTN). The Path Table reserves partial activated established 121 light-paths that can be used by subsequent requests for subsequent 122 services. If a subsequent service matches a light-path entry in the 123 Path Table, the controller does not need to establish a new end-to- 124 end light-path for this request and only assign the existing light- 125 path to this request for data transmission. This new routing 126 mechanism can reduce the network load and save a lot of path 127 computation time for some services. 128 2. Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 The following acronyms are used in this document. 136 SDN: Software-Defined Networking 138 SDON: Software-Defined Optical Networks 140 GMPLS: Generalized Multi-Protocol Label Switching 142 PCE: Path Calculation Element 144 RSVP: Resource Reservation Protocol 146 OSPF: Open Shortest Path First 148 TED: Traffic Engineering Database 150 ROADM: Reconfigurable Optical Add and Drop Multiplexer 152 3. Motivation of Path Table based Routing Mechanism 154 The traffic requests arrive and depart from the network dynamically 155 in a random manner. When a request arrives, the control plane must 156 immediately find a light-path available for the traffic demand. With 157 the frequent arrival and departure of service requests, the optical 158 transport networks need to dynamically establish and remove the end- 159 to-end light-path for each service request. The establishment and 160 removal of end-to-end light-path not only consume much time but also 161 will occupy the bandwidth of management channel. The software module 162 in the controller and optical devices need to produce and handle too 163 many messages to conduct path calculation and cross connection 164 configuration. In view of the flow table used at each OpenFlow- 165 enabled switch, we propose the Path Table for SD-OTN. Path Table 166 preserves the existing established light-paths which are not used by 167 any request currently. Taking advantage of Path Table, the controller 168 will first search the suitable light-path in the Path Table for each 169 request. If there exist one suitable light-path matching the current 170 request, the controller assigns the matched light-path to this 171 request. Otherwise, the controller will establish one end-to-end 172 light-path for this request. From the perspective of time statistical 173 point of traffics, the Path Table will get enormous benefits. 175 4. Path Table based Routing Architecture 177 This section first gives an overview of the architecture of Path 178 Table based routing model. 180 4.1. Architecture 182 Figure 1 below shows the component of a centralized controller with 183 PCE. PCE is a special computational component which can support 184 large, multi-domain, multi-region and multi-layer network constrain- 185 based path computation. The OpenFlow protocol is used to exchange 186 message between optical devices and controller. Service requests of 187 provisioning end-to-end light-path are received by the controller. 188 The controller will transmit the request to the PCE modular. The PCE 189 modular operates on the Path Table and TED to respond with the 190 requested path. 192 +-----------------------------------+ 193 | +-------+ Controller | 194 | | TED | | 195 | +-------+ | 196 | A | | 197 | | | | 198 | | V | 199 | +-------+ <-- +------------+ | 200 | | PCE | | Path Table | | 201 | +-------+ --> +------------+ | 202 | A | | 203 | | | | 204 | | V | 205 +---------------------------------- + 206 | SAL | 207 +-----------------------------------+ 208 A | 209 | | Southbound Protocol 210 | | 211 | V 212 +---------+ +---------+ +---------+ 213 | ROADM |--->| ROADM |--->| ROADM | 214 +---------+ +---------+ +---------+ 216 Figure 1 Path table based routing architecture 218 4.2. Path Table 220 The Path Table consists of a lot of path entries. Each path entry 221 represents one already established light-path in the SD-OTN and is 222 identified by its source-destination node and bandwidth. 224 +----------------------------+----------------------------------+ 225 | Match Fields | | | | | 226 +------+-----------+---------+Priority|Counters|Instru-|Timeouts| 227 |Source|Destination|Bandwidth| | |ctions | | 228 +------+-----------+---------+--------+--------+-------+--------+ 229 | A | B | 40G | 0 | 0 | 0 | 0 | 230 +------+-----------+---------+--------+--------+-------+--------+ 231 | C | D | 100G | 0 | 0 | 0 | 0 | 232 +------+-----------+---------+--------+--------+-------+--------+ 234 Table 1 Path table 236 Each path entry (as presented in Table 1) contains: 238 Match Fields: match the service requests. It consists of the source 239 node, destination node and bandwidth. 241 Source: the node at which the traffic uploads. 243 Destination: the node at which the traffic downloads. 245 Bandwidth: the assigned spectrum or wavelengths for the service 246 request. 248 Priority: matching precedence of the path entry. 250 Counters: updated when requests are matched. 252 Instructions: to send the request to next table or assign the matched 253 light-path to this request. 255 Timeouts: maximum amount of time or idle time before path is expired 256 by the controller. 258 4.3. Matching 260 +---------+ 261 | Request | 262 +---------+ 263 | <-------------------------------------+ 264 V | Yes 265 / \ | 266 /Match\ +---------------+ / \ 267 /in Tab-\ Yes |Update counters| /Goto\ 268 \ ble n / --------->| Excute |--> / Table\ 269 \ ? / | instructions | \ n ? / 270 \ / +---------------+ \ / 271 | No A \ / 272 V | | 273 / \ | | No 274 / \ | V 275 /Table- \ Yes | +------------------+ 276 /miss Path\ -----------------+ |Execute action set| 277 \ entry / +------------------+ 278 \ exist?/ 279 \ / 280 \ / 281 | 282 V 283 +-----------+ 284 |Reject this| 285 | request | 286 +-----------+ 288 Figure 2 Flowchart detailed request flow through in controller 290 Once a request arrives, the controller performs the functions as 291 shown in Figure 2. The controller starts with performing a table 292 lookup in the first path table and may perform table lookups in other 293 path tables. The source node, destination node and bandwidth are 294 extracted from the request. Light-path match fields used for table 295 lookups depend on the request's source-destination and bandwidth. 297 A request matches a path table entry if the source node, destination 298 node and bandwidth all match fields used for the lookup match those 299 defined in the path table entry. If a path table entry field has a 300 value of ANY (field omitted), it matches all possible values. The 301 request is matched with the path table and only the highest priority 302 light-path entry that matches the request must be selected. The 303 counters associated with the selected path entry must be updated and 304 the action included in the selected path entry must be carried out. 305 If there are multiple matched light-path entries with the same 306 highest priority, the selected light-path entry is explicitly 307 undefined. 309 4.4. Table-miss 311 Every path table must support a table-miss light-path entry to 312 process table misses. The table-miss flow entry specifies how to 313 process requests unmatched by other light-path entries in the path 314 table, may send the request to PCE or other controller. The table- 315 miss light-path entry is identified by its match and its priority, it 316 wildcards all match fields and has the lowest priority. The match of 317 the table-miss light-path entry must support sending the request to 318 the PCE. It also may support sending the request to the other 319 controller. The table-miss path entry behaves in the same way as any 320 other path entry, but it does exist by default in each path table. 322 4.5. Path Removal 324 Path entries are removed from path table in two ways, either via the 325 controller, or the light-path (path entry) expiry mechanism. 327 The path expiry mechanism is run dependently in the controller and it 328 is based on the state and configuration of path entries. Each path 329 entry has an idle timeout and a hard timeout associated it. If the 330 hard timeout field is non-zero, the controller must note the path 331 entry's arrival time, at it may need to evict the entry later. A non- 332 zero hard timeout field causes the path entry to be removed after the 333 given number of seconds, regardless of how many requests it has 334 matched. A non-zero idle timeout field causes the path entry to be 335 removed when it has matched no paths in the given number of seconds. 336 The controller must implement path expiry and remove path entries 337 from the path table when one of their timeouts is exceeded. 339 The controller may actively remove path entries from path table. Path 340 entries may be removed from path tables when controller needs to 341 reclaim resources. The controller selects the removed path depending 342 on path entry parameters, resource mapping in the controller and 343 other internal controller constraints. 345 4.6. Counters 346 Counters are maintained for each path table and path entry. Counters 347 may be implemented in software and maintained by polling hardware 348 counters with more limited ranges. Table 2 contains the set of 349 counters defined by our suggestions. A controller is not required to 350 support all counters, just those marked "required" in Table 2. 351 Duration refers to the amount of time the path entry has been 352 installed in the controller. 354 +---------------------------------+-------------+-------------+ 355 | Counter | Bits | | 356 +---------------------------------+-------------+-------------+ 357 | Per Flow Entry | 358 +---------------------------------+-------------+-------------+ 359 |Reference Count (active entries) | 32 | Required | 360 +---------------------------------+-------------+-------------+ 361 | Path Lookups | 64 | Optional | 362 +---------------------------------+-------------+-------------+ 363 | Path Matches | 64 | Optional | 364 +---------------------------------+-------------+-------------+ 365 | Per Path Entry | 366 +---------------------------------+-------------+-------------+ 367 | Received requests | 64 | Optional | 368 +---------------------------------+-------------+-------------+ 369 | Duration (seconds) | 32 | Optional | 370 +---------------------------------+-------------+-------------+ 371 | Duration (nanoseconds) | 32 | Optional | 372 +---------------------------------+-------------+-------------+ 374 Table 2 List of counters 376 4.7. Instructions 378 Each path entry contains a set of instructions which are executed 379 when a request matches the entry. A controller is not required to 380 support all instruction types, just those marked "Required 381 Instruction" below. 383 Optional Instruction: send the request to other controller. 385 Required Instruction: assign the matched light-path to this request. 387 Required Instruction: transmit this request to PCE 389 The instruction set associated with a path entry contains a maximum 390 of one instruction of each type. 392 5. Security Considerations 394 TBD 396 6. IANA Considerations 398 This document makes no request of IANA. 400 7. References 402 7.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 8. Acknowledgments 409 This document was prepared using 2-Word-v2.0.template.dot. 411 Authors' Addresses 413 Xin Li 414 Beijing University of Posts and Telecommunications 416 Email: xinli@bupt.edu.cn 418 Yu Zhou 419 Beijing University of Posts and Telecommunications 421 Email: shaxiaoziningyi@bupt.edu.cn 423 Dajiang Wang 424 ZTE Corporation 426 Email: wang.dajiang@zte.com.cn 428 Zhenyu Wang 429 ZTE Corporation 431 Email: wang.zhenyu1@zte.com.cn 433 Jiayu Wang 434 ZTE Corporation 436 Email: wang.jiayu1@zte.com.cn 438 Wenzhe Li 439 Beijing University of Posts and Telecommunications 441 Email: lwz@bupt.edu.cn 443 Shan Yin 444 Beijing University of Posts and Telecommunications 446 Email: yinshan@bupt.edu.cn 447 Shanguo Huang 448 Beijing University of Posts and Telecommunications 450 Email: shghuang@bupt.edu.cn