[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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,
              <http://www.rfc-editor.org/info/rfc2119>.

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]