idnits 2.17.1 draft-lt-rtgwg-pathid-engineering-00.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 date (December 24, 2015) is 3046 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5331' is mentioned on line 230, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG WG Ting. Liao 3 Internet-Draft Ting. Ao 4 Intended status: Standards Track ZTE Corporation 5 Expires: June 26, 2016 December 24, 2015 7 RTGWG PathID Engineering 8 draft-lt-rtgwg-pathid-engineering-00.txt 10 Abstract 12 With the deployment of centralized control, the traffic scheduling 13 can be easier to accomplish with PathID carried in the data plane. A 14 PathID used to indicate a flow through a forwarding path which is not 15 the default shortest path. It is encapsulated in the packet at the 16 ingress node, carried to indicate the forwarding at the transit node 17 and decapsulated at the egress node. 19 This document describes how to accomplish flexible forwarding with 20 PathID in traffic scheduling. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 26, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3 58 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. A new type of Ether Header . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 By the deployment of centralized control, the traffic scheduling is 71 becoming more and more important. Combining with the centralized 72 control and the provision of dynamic route learning in current 73 device, we propose a method using PathID to indicate how to schedule 74 the traffic. With this method, the controller under pure SDN is not 75 required to sent update forwarding message to every forwarding device 76 frequently, so that reduce the complexity of the controller, and make 77 the scheduling be easier. 79 This draft proposes a method by identifying a pathID to a specified 80 path, and carrying the pathID in the header of frames and forwarding 81 the frames along the specified path. The PathID is an ID used to 82 identify a Path which needs to be explicitly specified when frames 83 transit from source to destination. It means when the frames are not 84 transit on the default shortest path ( such as calculated by SPF OR 85 CSPF algorithm ), the non-default path specified by the operator or 86 controller is identified by a pathID. 88 The pathID is encapsulated in the packet at the ingress node, carried 89 to indicate the forwarding at the transit node and decapsulated at 90 the egress node. To get it, PathID status also needs to be 91 maintained in the intermediate forwarding node. But when the 92 application changes the path, the controller needs to re-calculate a 93 new dedicated path, and assign the old PID or a new PID to this path, 94 and send the mapping information of the PID and the path to all the 95 nodes on the new path. Every node needs to update or generate the 96 forwarding entry according to the mapping information received. 98 With this method, the controller needn't control all the nodes for 99 their forwarding entry separately, but only needs to send the same 100 mapping information to all the nodes. 102 2. Conventions and Abbreviations 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119] . 108 The following notations and abbreviations are used throughout this 109 draft. 111 PID: Path Identifier, a specified path or a non-default path is 112 identified by a Path ID (PID). The PID may be an unused label or an 113 unused ipv4 address or an unused ipv6 address. If the forwarding 114 table for PID is an isolated table, the PID could be any length 115 value, no matter it is used or not. 117 3. Solution Overview 119 In this document, we define the Path Identifier (PID) and a new type 120 of Ether Header. The path calculating and traffic scheduling are all 121 managed by a centralized node(controller). 123 1. Controller calculates a best dedicated path (non-default path) 124 that meets all the requirements according to the application, and 125 assign a PID to the corresponding path. Controller take the 126 responsibility of the management,assignment, distribution and relaim 127 of the PID. 129 2. Controller sends the mapping information between PID and the 130 dedicated path to all the nodes on the path. 132 3. The node receives the mapping information and generates the 133 forwarding entry. 135 4. The ingress node needs to encapsulate the traffic with PID so 136 that the traffic can be forwarded alone the dedicate path and then 137 the egress node will de-capsulate the traffic. 139 4. Control plane 141 In the deployment of centralized control scenario, the controller 142 obtains the topology of the network. And the controller calculates 143 different specified path based on different service requirement as 144 policy control needed. Then the controller allocates an PID for a 145 non-default path and sends the mapping message of the PID and all the 146 addresses of nodes or links on this path to all the nodes on this 147 path. When the nodes receives the mapping message, it generates a 148 forwarding item of the PID, and in the item, the egress-interface and 149 nexthop of the PID is the egress-interface and nexthop of the next 150 hop of itself on this path of itself. 152 The details shown as in the figure 1. 154 __ +----------------------+ 155 / _ | Controller | __ 156 / / +----------------------+_ \ 157 / / | | | | | \ \ \ 158 / / | | | | | \ \ \ 159 +---+ / +---+ | | +---+ | +---+ \ \+---+ 160 -------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 | 161 +---+ / +---+ | | +---+ | +---+ \ +---+ 162 | / | / \ | \ | \ | 163 | / | / \ | \ | \ | 164 +---+ +---+ +---+ +---+ +---+ 165 |R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|----------- 166 +---+ +---+ +---+ +---+ +---+ 168 Figure 1 Scenario 1 170 o The controller has the topology as figure 1 shown. 172 o The controller calculates a path from R1 to R10 that must forward 173 step to step as {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10} . 175 o The controller allocates an unused PID 10010(an unused label for 176 example) to identify the path {R1, R2, R4, R3, R5, R6, R8, R7, R9, 177 and R10}. 179 o The controller sends the mapping message about (PID) 10010 to the 180 path {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10(the loopback 181 address may used to identify the nodes)} to all the nodes on the 182 path. 184 o Each node (R1-R10) receives the mapping message, generates a 185 forwarding item of the PID. Take R4 for example, R4 learns the 186 mapping message, and it knows the next hop of itself on this path is 187 R3, then it looks up the forwarding table, and finds that the nexthop 188 and egress-interface to R3 is the link and adjacency to R3, so it 189 generates the next hop and egress-interface to the PID is the link 190 and adjacency to R3. 192 5. Data plane 194 A flow needs to transit on this path with the PID encapsulated in the 195 header. When the forwarding table about PID is a new table, the PID 196 header could be a new type of Ether Header. When PID is a label or a 197 IPv4 addres or IPv6 address that is compatible to the existing 198 encapsulation, the PID must be a new global label or IP address. If 199 it is a 20 bits lebal, the PID can also be encapsulated at the outer 200 layer of the label layer. If it is an IP address, the ingress node 201 and egress node could take a mapping action, that is on the ingress 202 node, mapping the destination address to PID, and on the egress node, 203 mapping the PID to destination address. 205 5.1. A new type of Ether Header 207 A new type( TBD,to be assigned by IANA) of Ether Headers is shown in 208 the figure 2 for example. The ingress node could encapsulate frames 209 with PID carried. 211 0 1 2 3 212 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | TYPE | Len |NHeader| ENTROPY | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | PID (veriable length) | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2 A new type of Ether Header 221 o TYPE: 4-bit. To identify the PID type is a label or an ipv4 222 addresses or an ipv6 addresses or other. 224 o NHeader: 4-bit. Identifies the type of payload immediately 225 following the PID Header. The field may take any of the following 226 values: 228 1: MPLS packet with downstream-assigned label at top of stack. 2: 229 MPLS packet with upstream-assigned label at top of stack (see 230 [RFC5331]). If this value of the Proto field is used, the I bit MUST 231 be set, and the BFR-id of the BFIR must be placed in the BFIR-id 232 field. The BFIR-id provides the "context" in which the upstream- 233 assigned label is interpreted. 3: Ethernet frame. 4: IPv4 packet. 234 6: IPv6 packet. 236 o Len: 4-bit unsigned integer, is the length of the PID header in 237 8-octet units, not including the first 4 octets. 239 o ENTROPY: This 20-bit field specifies an "entropy" value that can be 240 used for load balancing purposes. The BIER forwarding process may do 241 equal cost load balancing, but the load balancing procedure MUST 242 choose the same path for any two packets have the same entropy value 244 o PID: The PID assigned to the path, it could be a label or an ipv4 245 addresses or an ipv6 addresses or other length to identify the path. 246 If the forwarding table for pathID is an isolated table, the pathID 247 could be any length value, no matter it is used or not. 249 6. Security Considerations 251 TBD. 253 7. Acknowledgements 255 In progress. 257 8. IANA Considerations 259 TBD. 261 9. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 Authors' Addresses 270 Ting Liao 271 ZTE Corporation 272 No.50 Software Avenue 273 Nanjing, Jiangsu 210012 274 China 276 Phone: +86 25 88016576 277 Email: liao.ting@zte.com.cn 278 Ting Ao 279 ZTE Corporation 280 No.889 Bibo Rd 281 Shanghai 201203 282 China 284 Phone: +86 21 68897642 285 Email: ao.ting@zte.com.cn