RTGWG WG Ting. Liao Internet-Draft Ting. Ao Intended status: Standards Track ZTE Corporation Expires: June 26, 2016 December 24, 2015 RTGWG PathID Engineering draft-lt-rtgwg-pathid-engineering-00.txt Abstract With the deployment of centralized control, the traffic scheduling can be easier to accomplish with PathID carried in the data plane. A PathID used to indicate a flow through a forwarding path which is not the default shortest path. It is encapsulated in the packet at the ingress node, carried to indicate the forwarding at the transit node and decapsulated at the egress node. This document describes how to accomplish flexible forwarding with PathID in traffic scheduling. 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 June 26, 2016. Copyright Notice Copyright (c) 2015 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 Liao & Ao Expires June 26, 2016 [Page 1] Internet-Draft RTGWG PathID Engineering December 2015 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. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Control plane . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Data plane . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. A new type of Ether Header . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction By the deployment of centralized control, the traffic scheduling is becoming more and more important. Combining with the centralized control and the provision of dynamic route learning in current device, we propose a method using PathID to indicate how to schedule the traffic. With this method, the controller under pure SDN is not required to sent update forwarding message to every forwarding device frequently, so that reduce the complexity of the controller, and make the scheduling be easier. This draft proposes a method by identifying a pathID to a specified path, and carrying the pathID in the header of frames and forwarding the frames along the specified path. The PathID is an ID used to identify a Path which needs to be explicitly specified when frames transit from source to destination. It means when the frames are not transit on the default shortest path ( such as calculated by SPF OR CSPF algorithm ), the non-default path specified by the operator or controller is identified by a pathID. The pathID is encapsulated in the packet at the ingress node, carried to indicate the forwarding at the transit node and decapsulated at the egress node. To get it, PathID status also needs to be maintained in the intermediate forwarding node. But when the application changes the path, the controller needs to re-calculate a new dedicated path, and assign the old PID or a new PID to this path, and send the mapping information of the PID and the path to all the nodes on the new path. Every node needs to update or generate the forwarding entry according to the mapping information received. Liao & Ao Expires June 26, 2016 [Page 2] Internet-Draft RTGWG PathID Engineering December 2015 With this method, the controller needn't control all the nodes for their forwarding entry separately, but only needs to send the same mapping information to all the nodes. 2. Conventions and Abbreviations 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] . The following notations and abbreviations are used throughout this draft. PID: Path Identifier, a specified path or a non-default path is identified by a Path ID (PID). The PID may be an unused label or an unused ipv4 address or an unused ipv6 address. If the forwarding table for PID is an isolated table, the PID could be any length value, no matter it is used or not. 3. Solution Overview In this document, we define the Path Identifier (PID) and a new type of Ether Header. The path calculating and traffic scheduling are all managed by a centralized node(controller). 1. Controller calculates a best dedicated path (non-default path) that meets all the requirements according to the application, and assign a PID to the corresponding path. Controller take the responsibility of the management,assignment, distribution and relaim of the PID. 2. Controller sends the mapping information between PID and the dedicated path to all the nodes on the path. 3. The node receives the mapping information and generates the forwarding entry. 4. The ingress node needs to encapsulate the traffic with PID so that the traffic can be forwarded alone the dedicate path and then the egress node will de-capsulate the traffic. 4. Control plane In the deployment of centralized control scenario, the controller obtains the topology of the network. And the controller calculates different specified path based on different service requirement as policy control needed. Then the controller allocates an PID for a non-default path and sends the mapping message of the PID and all the Liao & Ao Expires June 26, 2016 [Page 3] Internet-Draft RTGWG PathID Engineering December 2015 addresses of nodes or links on this path to all the nodes on this path. When the nodes receives the mapping message, it generates a forwarding item of the PID, and in the item, the egress-interface and nexthop of the PID is the egress-interface and nexthop of the next hop of itself on this path of itself. The details shown as in the figure 1. __ +----------------------+ / _ | Controller | __ / / +----------------------+_ \ / / | | | | | \ \ \ / / | | | | | \ \ \ +---+ / +---+ | | +---+ | +---+ \ \+---+ -------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 | +---+ / +---+ | | +---+ | +---+ \ +---+ | / | / \ | \ | \ | | / | / \ | \ | \ | +---+ +---+ +---+ +---+ +---+ |R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|----------- +---+ +---+ +---+ +---+ +---+ Figure 1 Scenario 1 o The controller has the topology as figure 1 shown. o The controller calculates a path from R1 to R10 that must forward step to step as {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10} . o The controller allocates an unused PID 10010(an unused label for example) to identify the path {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10}. o The controller sends the mapping message about (PID) 10010 to the path {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10(the loopback address may used to identify the nodes)} to all the nodes on the path. o Each node (R1-R10) receives the mapping message, generates a forwarding item of the PID. Take R4 for example, R4 learns the mapping message, and it knows the next hop of itself on this path is R3, then it looks up the forwarding table, and finds that the nexthop and egress-interface to R3 is the link and adjacency to R3, so it generates the next hop and egress-interface to the PID is the link and adjacency to R3. Liao & Ao Expires June 26, 2016 [Page 4] Internet-Draft RTGWG PathID Engineering December 2015 5. Data plane A flow needs to transit on this path with the PID encapsulated in the header. When the forwarding table about PID is a new table, the PID header could be a new type of Ether Header. When PID is a label or a IPv4 addres or IPv6 address that is compatible to the existing encapsulation, the PID must be a new global label or IP address. If it is a 20 bits lebal, the PID can also be encapsulated at the outer layer of the label layer. If it is an IP address, the ingress node and egress node could take a mapping action, that is on the ingress node, mapping the destination address to PID, and on the egress node, mapping the PID to destination address. 5.1. A new type of Ether Header A new type( TBD,to be assigned by IANA) of Ether Headers is shown in the figure 2 for example. The ingress node could encapsulate frames with PID carried. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | Len |NHeader| ENTROPY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID (veriable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 A new type of Ether Header o TYPE: 4-bit. To identify the PID type is a label or an ipv4 addresses or an ipv6 addresses or other. o NHeader: 4-bit. Identifies the type of payload immediately following the PID Header. The field may take any of the following values: 1: MPLS packet with downstream-assigned label at top of stack. 2: MPLS packet with upstream-assigned label at top of stack (see [RFC5331]). If this value of the Proto field is used, the I bit MUST be set, and the BFR-id of the BFIR must be placed in the BFIR-id field. The BFIR-id provides the "context" in which the upstream- assigned label is interpreted. 3: Ethernet frame. 4: IPv4 packet. 6: IPv6 packet. o Len: 4-bit unsigned integer, is the length of the PID header in 8-octet units, not including the first 4 octets. Liao & Ao Expires June 26, 2016 [Page 5] Internet-Draft RTGWG PathID Engineering December 2015 o ENTROPY: This 20-bit field specifies an "entropy" value that can be used for load balancing purposes. The BIER forwarding process may do equal cost load balancing, but the load balancing procedure MUST choose the same path for any two packets have the same entropy value o PID: The PID assigned to the path, it could be a label or an ipv4 addresses or an ipv6 addresses or other length to identify the path. If the forwarding table for pathID is an isolated table, the pathID could be any length value, no matter it is used or not. 6. Security Considerations TBD. 7. Acknowledgements In progress. 8. IANA Considerations TBD. 9. 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, . Authors' Addresses Ting Liao ZTE Corporation No.50 Software Avenue Nanjing, Jiangsu 210012 China Phone: +86 25 88016576 Email: liao.ting@zte.com.cn Liao & Ao Expires June 26, 2016 [Page 6] Internet-Draft RTGWG PathID Engineering December 2015 Ting Ao ZTE Corporation No.889 Bibo Rd Shanghai 201203 China Phone: +86 21 68897642 Email: ao.ting@zte.com.cn Liao & Ao Expires June 26, 2016 [Page 7]