Network Working Group                                          X. Tan
Internet Draft                                    Huawei Technologies
Intended status: Standard Track                         June 22, 2016
Expires: December 2016



                 Proactive Routing Network Architecture
         draft-tan-rtgwg-proactive-routing-network-arch-00.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be
   modified, and derivative works of it may not be created, and it
   may not be published except as an Internet-Draft.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be
   modified, and derivative works of it may not be created, except to
   publish it as an RFC and to translate it into languages other than
   English.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s)
   controlling the copyright in such materials, this document may not
   be modified outside the IETF Standards Process, and derivative
   works of it may not be created outside the IETF Standards Process,
   except to format it for publication as an RFC or to translate it
   into languages other than English.

   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



Tan                   Expires December 22, 2016              [Page 1]

Internet-Draft        Proactive Routing Network             June 2016


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 22, 2016.

Copyright Notice

   Copyright (c) 2016 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 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.

   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

   Proactive Routing Network (PRN), which runs on conventional
   network, is user and service experience oriented; and provides a
   set of E2E Pipes for the two End Systems of communication named
   Requester and Source. The E2E Pipe have deterministic path learned
   from the trace of the Request sent by Requester, and is QOS
   guaranteed by resource reservation. Addressing issue is solved by
   recording the labeled interfaces or Local Pipes taken along with
   the Request to the Source. Each Pipe is protocol oblivious,
   application aware, elastic and visible for users and operators.

   PRN is not a new network, rather, it is a service attached to the
   conventional network. Therefore it does not affect the operation
   business of the conventional networks, so it is very conducive to
   the deployment and smooth evolution.

   PRN is valuable for users who want deterministic network service,
   and is helpful for operators to simplify the service management
   and easy for fault location and billing, and is helpful for
   vendors to solve the addressing issue which is one of the biggest
   challenges of increasing device throughput at a reasonable cost.




Tan                   Expires December 22, 2016              [Page 2]

Internet-Draft        Proactive Routing Network             June 2016


Table of Contents


   1. Introduction.................................................. 3
      1.1. Background............................................... 4
      1.2. PRN...................................................... 4
   2. Conventions used in this document............................. 6
   3. Terminology................................................... 6
   4. Proactive Routing Network Architecture........................ 7
      4.1. Overview................................................. 7
      4.2. Session Model............................................ 7
         4.2.1. Session Description................................. 9
         4.2.2. QOS Requirement..................................... 9
         4.2.3. Capacity & Status Advertisement..................... 9
         4.2.4. Exception Handling................................. 10
      4.3. Network Model........................................... 10
         4.3.1. Session Awareness.................................. 11
         4.3.2. Proactive Routing.................................. 12
         4.3.3. Path Exploration................................... 14
         4.3.4. Source Route Forwarding............................ 15
      4.4. Application & Service Model............................. 15
         4.4.1. Application Model.................................. 15
         4.4.2. QOS Model.......................................... 16
         4.4.3. OAM Model.......................................... 16
      4.5. Protocol Model.......................................... 16
         4.5.1. SD................................................. 16
         4.5.2. SRL................................................ 17
         4.5.3. RPI................................................ 17
         4.5.4. QOS................................................ 17
   5. Other Considerations......................................... 17
      5.1. Scalability............................................. 17
         5.1.1. Number of Local Pipe............................... 18
         5.1.2. Processing Overhead................................ 18
         5.1.3. Depth of SRL....................................... 18
      5.2. Resiliency.............................................. 19
      5.3. Evolution............................................... 19
   6. Use Cases.................................................... 19
   7. Security Considerations...................................... 19
   8. IANA Considerations.......................................... 19
   9. Conclusions.................................................. 19
   10. References.................................................. 19
      10.1. Normative References................................... 19
      10.2. Informative References................................. 20
   11. Acknowledgments............................................. 20

1. Introduction

   Proactive Routing Network (PRN), which runs on conventional
   network, is user and service experience oriented; and provides a
   set of E2E Pipes for the two End Systems of communication named
   Requester and Source. Requester ask for data from the Source by


Tan                   Expires December 22, 2016              [Page 3]

Internet-Draft        Proactive Routing Network             June 2016


   Request in PRN. The E2E Pipe have deterministic path learned from
   the trace of the Request by Source Route, and QOS guaranteed by
   resource reservation. Addressing issue is solved by recording the
   labeled interfaces or Local Pipes taken along with the Request to
   the Source. Each Pipe is protocol oblivious, application aware,
   elastic and visible for users and operators.

   PRN is aimed at resolving the scalability problem caused by
   addressing issue as described in RFC4984[RFC4984]. With QoS
   Signaling mechanisms, PRN can provides deterministic network
   service for users especially for the application requiring ultra-
   high through-put and ultra-low delay such as VR. Obviously, PRN is
   helpful for operators to simplify the service management and easy
   for fault location and billing.

   So far, PRN applies only to point to point and connection oriented
   communication. For point to multipoint or connectionless
   communication, further study is needed.

1.1. Background

   The global information and communication industry is evolving very
   fast. Various internet business growing very fast. New
   applications and fast growing internet business promote the coming
   of the BIG data era. The "BIG" represents in the following
   aspects:

   BIG traffic volume: Big video and cloud computing etc. increase
   the network traffic greatly. It is expected that the throughput of
   core router will be required to reach to 1P by 2025.

   BIG scale: The network boundary is expanded greatly by a lot of
   factors, such as IOT, IPV6, etc. It is expected that the physical
   connection of internet will reach to 100 billion by 2025.

   BIG range of applications: Network applications not limited to
   Web, eMail and Telnet etc. Big video such as VR, the bandwidth
   killer application, and many industrial applications bring great
   challenges to network architecture, including ultra-high
   throughput, strict controlled delay and jitter, explicit and
   stable forwarding path and forwarding behavior, etc.

   In a nutshell, the challenge of the network especially for
   operators and vendors is BIG.

1.2. PRN

   As shown the figure below, the Requester send a Request to the
   Source via the network, as the response, the Source send the
   requested data back to the Requester.



Tan                   Expires December 22, 2016              [Page 4]

Internet-Draft        Proactive Routing Network             June 2016


   o---------o
    |         |---------------------o
    | Source  |>>>>>>>>>>>>>>>>>>v  |
    o---------o                  v  |
           |      Local Pipe 4   v  |
           |                     v  |
           |                     v  |
           |                     v  |
           |                     v  |
       o---------o             o---------o
       |    R    |             |    R    |
       |    2    |-------------|    1    |-----(SubNetwork x)
       o---------o             o-v-------o
           |                     v  |
           |      Local Pipe 3   v  |
           |                     v  |
           |                     v  |
           |                     v  |
       o---------o             o---------o
       |    R    |             |    R    |
       |    3    |-------------|    4    |-----(SubNetwork y)
       o---------o             o-v-------o
                                 v  |
                   Local Pipe 2  v  |
                                 v  |
                                 v  |
                                 v  |
    o---------o   Local Pipe 1 o---------o
    |         | <<<<<<<<<<<<<<<<    R    |
    |Requester|----------------|    5    |
    o---------o                o---------o

                              <PRN Overview>

   The Request from the Requester go through R5, R4 and R1 and then
   reach the Source. During this process each PRN Node create a
   reverse Local Pipe as following steps.

   First, R5 create the Local Pipe 1 to connect the Requester when
   the Request arrived at R5, and forward the Request to R4 with the
   information of Local Pipe 1.

   Second, R4 and R1 do the same as R5 to create the Local Pipe 2 and
   Local Pipe 3, in which the Local Pipe 2 connect to R5 and the
   Local Pipe 3 connect to R4.

   At last, the Request arrives at the Source, and OPTIONALLY the
   Source create the Local Pipe 4 which is not in scope of PRN.

   The E2E Pipe is created when the Request arrive at the Source, by
   source routing paradigm, the Source enforces the Data Flow through


Tan                   Expires December 22, 2016              [Page 5]

Internet-Draft        Proactive Routing Network             June 2016


   the E2E Pipe, that is packet flow through the Local Pipe 3, the
   Local Pipe 2 and the Local Pipe 1 in order as shown in the above
   figure.

   The Local Pipe 1, 2, and 3 compose a PRN for the session triggered
   by the Request, of course, the PRN can have more Pipes if the node
   do multiple path exploration in the above first and second steps.

2. Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

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

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to
   be    interpreted as carrying significance described in RFC 2119.

   In this document, the characters ">>" preceding an indented
   line(s)   indicates a statement using the key words listed above.
   This convention aids reviewers in quickly identifying or finding
   the portions of this RFC covered by these keywords.

3. Terminology

   PRN: Proactive Routing Network, a virtual network, and the
   mechanism to create the network.

   PRN node: A Node with PRN enabled.

   End System: A terminal or host or any other which end a packet or
   traffic.

   Requester: An End System sending the request to data source to ask
   for data or information.

   Request: A packet sent by Requester, especially the first packet
   to start a session.

   Source: The End System sending data to the Requester in response
   to the Request.

   Data Flow: A stream of packets from Source to Requester.

   Previous Hop: A PRN node on the packet network path immediately
   before the node currently processing the packet.



Tan                   Expires December 22, 2016              [Page 6]

Internet-Draft        Proactive Routing Network             June 2016


   Next Hop: A PRN node on the packet network path immediately after
   the node currently processing the packet.

   Local Pipe: A pipe created by a PRN node to its Previous Hop.

   E2E Pipe: A pipe from one end system to the other end system
   composed by an ordered list of Local Pipe.

   Upstream Pipe: An E2E Pipe from Requester to Source.

   Downstream Pipe: An E2E Pipe from Source to Requester.

   SRL: Source Routing Label list, an ordered list of Local Pipe's
   Label or Source Routing Label.

   RPI: Reverse Path Information, an ordered list of Local Pipe
   information or Reverse Pipe Information.

4. Proactive Routing Network Architecture

   In this section, the main concepts, architecture and related
   methods of PRN, are described.

4.1. Overview

   PRN architecture includes the Basic Function Model, Application &
   Service Model and Protocol Model.

   The three basic functions of PRN are Conventional Network(s),
   Session model and Network model:

   o  Conventional Network(s) is the basic operating infrastructure
      for PRN, such as IP, MPLS and ETH network, etc. PRN does not
      change the basic mechanism of the conventional network, but
      have some requirements for it, such as considering more aspects
      when select the next hop to forward Request packet.
      Conventional network(s) does not belong to the scope of this
      document and no further description about it.

   o  Session Model defines how a session is established in PRN
      environment, and describes the negotiation operation between
      End System and PRN.

   o  Network Model defines how to build, maintain and tear PRN.

4.2. Session Model

   Data Model on network can be categorized as Pull Model and Push
   Model, of which Push Model can be further classified as
   Unsolicited Push and Solicited Push. Pull Model and Solicited Push
   model have the common characteristic, that is, the session MUST be


Tan                   Expires December 22, 2016              [Page 7]

Internet-Draft        Proactive Routing Network             June 2016


   started from the Requester by sending a Request to the data
   Source. Unsolicited Push model is not considered currently.

   The figure below shows the Session Model. The data Requester send
   Request to the data Source via the network, normally, the data
   Source segment and encapsulate the requested data into packets and
   send back to the Requester via network. The packet stream from the
   Source to the Requester is named Data Flow in the figure.

        o-----------------------------------o       o-------------------------o
        |     +-------------------------+   |       |  +-------------------+  |
        |     |        Requester        |   |       |  |      Source       |  |
        |     +-------------------------+   |       |  | Application Layer |  |
        |     |     Application Layer   |   |       |  +--x-x---x-x----x-x-+  |
        |     +-------------------------+   |       |     v ^   v ^    v ^    |
        o------x-x---------x-x-----x-x------o       |   +-x-x--+x-x+  +x-x+   |
               ^ |         ^ |     ^ | Request      |   |  O   |TCP|  | P |   |
     Data Flow ^ v         ^ v     ^ v              |   |  S   | / |  | R |   |
     o---------x-x---------x-x-----x-x---------o    |   |  I   | IP|  | N |   |
     |    +------------+ +-----+ +-----+       |    |   +----------+  |   |   |
     |    |Presentation| |     | |     |       |    |   |  Network |  |   |   |
     |    +------------+ |Trans| |  P  |       |    |   +----------+  +---+   |
     |    |   Session  | |port | |  R  |       |    |   Data Link & Physical  |
     |    +------------+ |     | |  N  |       |    o----------x-x------------o
     |    |  Transport | |     | |Layer|       |     Data Flow v ^ Request
     |    +------------+-+-----+ |     |       |      o--------x-x-----------o
     |    |        Network     | |     |       |      |Network(Router/Switch)|
     |    +--------------------+ +-----+       |      |   +-----+  + ---- +  |
     o-------------------x-x-------------------o      |   |  P  |  |IP/ETH|  |
                         ^ |                          |   |  R  |  |/MPLS.|  |
                         ^ v                          |   |  N  |  |Conven|  |
          o--------------x-x---------------o          |   |Pipe |  |tional|  |
          |    +-----------------------+   |          |   +-----+  +------+  |
          |    |        Data Link      |   | Data Flow| +------------------+ |
          |    +-----------------------+   x <<<<<<<< x |   Data Link      | |
          |    |        Physical       |   x -------> x |   &Physical      | |
          |    +-----------------------+   | Request  | +------------------+ |
          o--------------------------------o          o----------------------o

                              Session Model

   In addition to the traditional information such as the destination
   address and port number to tell the Source what is requested, the
   Request SHOULD also carry session traffic description, QOS
   requirements, the capacity of the End System, and exception
   handling definitions.

   Network forward the Request to the Source, and at the same time a
   PRN is created for the Data Flow which contains one or more E2E
   Pipes. The Source send the Data Flow via the selected Pipe.



Tan                   Expires December 22, 2016              [Page 8]

Internet-Draft        Proactive Routing Network             June 2016


   The Source can correct Session Description, adjust QOS
   requirements or redefine Exception Handling. The modified
   information SHOULD be carried in the Data Flow packet. PRN will
   advertisement the newest status of the E2E Pipe when the Pipe is
   built or changed. By this way, the Source, the Requester and the
   PRN inform or negotiate with each other about the session and the
   Pipe.

   Although the negotiation process can take place at any stage of
   the session, but generally only in the initial stage, that is only
   the Request and the first packet of the Data Flow will carry the
   session description and QOS information.

   In order to make PRN Node remove the Pipe and release the related
   resources at the end of the session, the last packet of the Data
   Flow SHOULD carry the necessary session description and QOS
   information. Similarly, by the end of session, the Source SHOULD
   send a packet carrying the above necessary information on the
   backup Pipe if have any.

4.2.1. Session Description

   Session Description SHOULD accurately describes the session
   characteristics as RSVP do, and there SHOULD have necessary
   information to identify the packet in the session such as the
   first or the last packet of the session. Obviously the first
   packet is the Request triggering the PRN creation for the session
   and the last packet will be used to tear the PRN.

4.2.2. QOS Requirement

   QOS Requirement SHOULD be defined as goal oriented, so it SHOULD
   define the effect but not the means of QOS. Generally it SHOULD
   include the bandwidth, delay, and jitter etc., as well as the
   minimum lever of QOS if the demand cannot be met.

4.2.3. Capacity & Status Advertisement

   All the elements involved in PRN, including the End System and PRN
   Node MUST advertise if it is PRN enabled. If the End System does
   not support PRN, the network SHOULD select a PRN node as the proxy
   for the session.

   Other advertisement are OPTIONAL, if there haven't the
   advertisement for an ability, that means the entity does not have
   this ability; if there haven't the advertisement about a status,
   that means the state is ok to meet the demand, without any
   exception.





Tan                   Expires December 22, 2016              [Page 9]

Internet-Draft        Proactive Routing Network             June 2016


4.2.4. Exception Handling

   Exception Handling defines the action when the network or the peer
   End System have some problems to meet the requirements. Generally
   it associated with the QOS Requirements.

   Exception handling is OPTIONALLY given by the End System.

4.3. Network Model

   Network Model includes PRN nodes and the network composed by it,
   and the End System connected to the network. As shown in Figure
   below, there are a PRN created for the session which is initiated
   by the Requester to ask data from the Source. This PRN has only
   one E2E Pipe which is composed by Local Pipe 1, Local Pipe 2 and
   Local Pipe 3.

    o---------o
    |   Data  |---------------------o
    | Source  |                     |
    o---------o>>>>>>>>>>>>>>>>>>v  |
           |      Local Pipe 4   v  |
           |                     v  |
           |                     v  |
           |                     v  |
           |                     v  |
       o---------o             o---------o
       |    R    |             |    R    |
       |    2    |-------------|    1    |-----(SubNetwork x)
       o---------o             o-v-------o
           |                     v  |
           |      Local Pipe 3   v  |
           |                     v  |
           |                     v  |
           |                     v  |
       o---------o             o---------o
       |    R    |             |    R    |
       |    3    |-------------|    4    |-----(SubNetwork y)
       o---------o             o-v-------o
                                 v  |
                   Local Pipe 2  v  |
                                 v  |
                                 v  |
                                 v  |
    o---------o   Local Pipe 1 o---------o
    |   Data  | <<<<<<<<<<<<<<<<    R    |
    |Requester|----------------|    5    |
    o---------o                o---------o

                              Network Model



Tan                   Expires December 22, 2016             [Page 10]

Internet-Draft        Proactive Routing Network             June 2016


   The link connecting the End System and PRN Node or the link
   between two PRN Nodes can be a physical link, or a virtual link
   such as LSP or GRE tunnel by which the E2E Pipe can pass through
   the conventional network, or a PRN E2E Pipe by which PRNs can be
   cascaded.

   The Request is forwarded by PRN Node hop by hop. Besides the
   conventional forwarding process, each PRN Node intercept the
   session information such as Session Description and QOS from the
   Request, and create a Local Pipe to the Previous Hop. When forward
   the Request to the Next Hop, the Local Pipe's information named
   RPI is inserted in the Request packet.

   The Source obtains the Local Pipes which composed the E2E Pipe
   connecting to the Requester. As shown above, the E2E Pipe is
   composed by the Local Pipe 1, 2, 3. The Local Pipe 4 is OPTIONALLY
   created by the Source which is not part of the PRN.

   The Source encapsulates the Local Pipes' label in a Source Routing
   diagram such as SRL(Source Routing Label list). As the above
   example, the label for Local Pipe 1, 2, 3 is 1, 2, 3, then the SRL
   SHOULD be encoded as {3,2,1}.

   Each PRN Node get the right label advertised by itself, then get
   the corresponding Local Pipe from which the output interface and
   other information can be used to process and forward the packet to
   the next PRN Node.

   PRN supports multiple E2E Pipes exploration by explicit request
   from Requester or local configuration of the PRN Node. For
   example, another E2E Pipe crossing the R2 or R3 or both can be
   created for the PRN showed by the above figure.

   Thus, PRN Network Model contains the following elements: Session
   Awareness, Proactive Routing, Path Exploration and Source Route
   Forwarding.

4.3.1. Session Awareness

   PRN Node MUST cognize the first packet of a session which is the
   so called the Request. Although there are many ways, this document
   propose it SHOULD be explicitly flagged by the End System
   initiating the session.

   PRN Node MUST cognize the last packet by which the PRN Node tear
   down the Local Pipe and release the related resources. Of course,
   PRN node SHOULD be capable of aging the Local Pipe by detecting
   the Data Flow's traffic.

   PRN Node SHOULD be aware of the other information of the session
   from packet, such as QOS by which PRN Node can make proper


Tan                   Expires December 22, 2016             [Page 11]

Internet-Draft        Proactive Routing Network             June 2016


   resource reservation for the Local Pipe and take it as a key
   consideration to select the Next Hop for the Request.

   If the necessary information cannot be obtained from packet, PRN
   Node SHOULD process reasonably based on well-known logic or local
   configuration. For example, receiving a TCP_SYN packet, PRN Node
   SHOULD be able to reasonably infer that there will be a Data Flow
   from the server to the client, although there haven't Session
   Description in the packet.

4.3.2. Proactive Routing

   When Received a Request, PRN Node creates a Local Pipe to the
   Previous Hop and forward the Request with the Local Pipe's
   information to the Next Hop. This process is called Proactive
   Routing.

   PRN Node MUST assigns a local unique label for the Local Pipe
   created by it, and MUST advertise the label to the Next Hop along
   the Request.

   Besides the label, PRN Node SHOULD advertise the other information
   about the Local Pipe such as QOS and link attributes. The Local
   Pipe information including the label is encoded in RPI and
   inserted in the Request packet before which is forwarded to the
   Next Hop.

   A Local Pipe can have multiple labels, but one label MUST belong
   to only one Local Pipe. The label MUST be kept unchanged once
   assigned to a session. Label has only local significance, and the
   PRN Node MUST be able to find the corresponding Local Pipe solely
   by the label it advertised.

   The other end of the Local Pipe MUST be the Previous Hop on the
   Request path, and MUST be kept unchanged once the Local Pipe is
   created. The Local Pipe SHOULD have other information to speed up
   packet procession such as Packet Edition or Prepositioning.

   PRN Node SHOULD report the status or change the Local Pipe's
   configuration in response to the request from the End System, and
   the information SHOULD be carried along with the packet giving the
   request information.

   Source obtains the RPIs advertised by the PRN Nodes, and the
   Source MUST encapsulates the Data Flow packet with the Local
   Pipes' label in a Source Routing format such as SRL described in
   PRN Protocol Model in order to enforce the packet pass through the
   Local Pipes.

   Local Pipe can be shared by multiple Data Flows or Sessions, but
   PRN Node SHOULD create a separate Local Pipe for a Data Flow with


Tan                   Expires December 22, 2016             [Page 12]

Internet-Draft        Proactive Routing Network             June 2016


   strict QOS requirement. PRN don't make any assumption on the
   detail mechanism for QOS but only define the effect. The PRN Node
   MUST meet the commitment advertised in its RPI.

   PRN Node SHOULD reuse the label advertised by the Previous Hop
   when find a local unique label for a Local Pipe, but the method
   about how to reuse label is not described herein.

   If PRN Node reuse the label advertised by the Previous Hop, it
   MUST make sure the label is locally unique and MUST tell the
   Source through RPI. The Source SHOULD merge the labels reused by
   different nodes to one label with the reused number.

   PRN node SHOULD minus one the number after processing the label,
   and delete it if the number is zero before sending the packet to
   next hop. Obviously, PRN node can reuse only the label advertised
   by the Previous Hop.

   PRN Node may need to reserve resource in order to guarantee QOS.
   The resource reservation can be done at the Local Pipe creating
   time, or just do part of it such as assigning a output TM queue
   for the Data Flow and left the bandwidth be reserved when the
   first Data Flow packet arrived which SHOULD carry with the newest
   QOS requirement. Whatever the case, PRN Node SHOULD check the
   related resources and MUST advertise the status and the QOS
   commitment by the Local Pipe along the Request to inform the
   Source.

   PRN allow the End System to inquire the pipes' information or
   change the QOS requirement by in-band mode. PRN Node SHOULD
   advertise the newest status of the Local Pipe whenever it is
   changed.

   PRN node SHOULD be able to insert the OAM information such as the
   processing time or queuing time in RPI if the End System requests
   or the operator demands by configuration. OAM Model latter will
   describe the operation in detail.

   PRN node SHOULD do as the Exception Handling defined by the End
   System or local configuration when it is impossible to meet the
   minimum requirements.

   PRN node SHOULD be aware of the end of the Data Flow; As described
   in Session Model, the Source SHOULD send a end signal when the
   Data Flow ends, or PRN node SHOULD monitor the traffic changes of
   the Data Flow to infer the end signal, such as if there have no
   traffic through the Local Pipe for a time then the Local Pipe can
   be released.

   PRN build the Upstream Pipe transporting Data Flow from Source to
   Requester by the Request sent from Requester to Source, similarly


Tan                   Expires December 22, 2016             [Page 13]

Internet-Draft        Proactive Routing Network             June 2016


   a Downstream Pipe can be built by the Request sent from Source to
   Requester. The Request sent from Source to Requester can be a
   separate packet or a Data Flow packet with request information. If
   the latter, the Upstream Pipe is exactly symmetrical with Upstream
   Pipe and PRN node SHOULD bind the corresponding Local Pipe. If the
   former, the process is exactly the same as the process to build
   the Upstream Pipe, but the Source and the Requester exchange their
   role, in this case, we can think there are two different PRNs.

4.3.3. Path Exploration

   The Downstream Pipe's path is exactly symmetric with the Request
   network path, so the process on each PRN node to choose the Next
   Hop for the Request is the Path Exploration for the E2E Pipe.

   There are many ways to find the Next Hop for the Request,
   including searching FIB by DIP or MAC table by DMAC table, a SDN
   way or SR way, etc. These basic mechanisms are out of scope of
   PRN.

   In addition to just considering for the Request as conventional
   method, PRN node SHOULD check the status of the system load and
   the link connecting to this node of the Next Hop in order to guide
   the Data Flow arriving from the best node and link. PRN node
   SHOULD choose the Next Hop with a link best matching the
   requirements of the session and MUST NOT choose the Next Hop which
   is too overloaded to create more Local Pipe.

   PRN node SHOULD send Request to multiple qualified Next Hops when
   the Request ask to explore multiple paths explicitly or by the
   local configuration. When do multipath exploration, PRN MUST make
   sure there is only one Master copy of the Request, that is when
   the received Request is Slaver, then all the copy the PRN node
   send to Next Hops MUST be Slaver, Otherwise, the PRN node MUST
   mark the copies as Slaver but keep one as Master.

   In this case, the Source may receive multiple copies of the
   Request each of which carries a different E2E Pipe. If the Request
   destination address is Anycast or alike, the Source MUST wait for
   the Master before collecting and selecting the E2E Pipe(s) from
   the copies, then responds the Requester and send the Data Flow to
   it by the selected E2E Pipe(s).

   PRN Node SHOULD be able to intercept the RPI information from the
   received Requests, and learn from it to get the backup Local Pipe
   sequences which can arrive the same Local Pipe of a PRN Node. When
   the PRN Node detect some faults on a downstream Local Pipe
   (normally the Local Pipe created by itself), it can do Local Path
   Repair for the packet to bypass the faulty Local Pipe.




Tan                   Expires December 22, 2016             [Page 14]

Internet-Draft        Proactive Routing Network             June 2016


4.3.4. Source Route Forwarding

   The Source collect the RPIs from each Request copy, and send Data
   Flow to the Requester through one or more Downstream Pipes which
   is selected by the Source independently according to the
   information carried in RPIs.

   Each E2E Pipe is represented by an ordered label list, and the
   Source MUST take it with the Data Flow packet to enforce the
   packet through the dedicated Local Pipes in order.

   Source Routing or Explicit Routing can have many forms, such as
   the forms proposed by SR. PRN propose the PRN form which will be
   described in Protocol Model.

4.4. Application & Service Model

   PRN provides deterministic, protocol oblivious, application aware,
   elastic and visible E2E Pipe for users.

   Deterministic, means the path of the E2E Pipe is fixed or pinned
   during the whole lifetime of the session, and can have
   deterministic or predictable delay and jitter.

   Protocol Oblivious, means the payload transported in the E2E Pipe
   can be anything even a structured bit stream.

   Application aware, means each PRN Node can be aware of the
   requirements from application, Local Pipe and E2E Pipe can be at
   application or flow grain.

   Elastic, means the QOS can be absolutely guaranteed, and can also
   be adaptive according to the network state under user permission,
   and user have the flexibility to use the E2E Pipes or the Local
   Pipes freely by Source Routing.

   Visible, means E2E Pipe and Local Pipe is visible to user and
   operator, the path is deterministic, the status and the attribute
   of each Local Pipe are advertised by RPI to user and operator.

   Application Model, QOS and OAM model are described below, each
   give some examples of using PRN to satisfy different applications.

4.4.1. Application Model

   As described above, currently PRN does not support Unsolicited
   Push data model, and PRN cannot promise zero packet loss ratio, so
   PRN MUST cooperate with other mechanism to make reliable
   transaction such as TCP acknowledgement mechanism or 1+1
   protection mechanism which is out of scope of PRN.



Tan                   Expires December 22, 2016             [Page 15]

Internet-Draft        Proactive Routing Network             June 2016


   Solicited Push Model

   TBD.

   Unidirectional Pull Model

   TBD.

   Bidirectional Pull Model

   TBD.

4.4.2. QOS Model

   TBD.

4.4.3. OAM Model

   TBD.

4.5. Protocol Model

   This document propose a new protocol layer, the PRN layer, as
   shown in the following figure.

       +---------+----------+----------------------+
       | Layer 2 |   PRN    | Data(Optional L3/L4) |
       +---------+----------+----------------------+

                              Protocol Model

   PRN layer is between the Layer 2 and the Layer 3, as described in
   Session Model, PRN layer can interact directly with application
   layer and have network path information, so the Layer 3 and Layer
   4 is optional once the PRN is created.

   There MUST have a new protocol ID in Layer 2 header to indicate
   PRN layer is followed. IANA section describe this issue.

   PRN layer contains SD, SRL, RPI and QOS fields, not all fields are
   required for any packet in a session.

4.5.1. SD

   SD, Session Description. It MUST have First, Last, SRL, RPI, QOS
   flags. SD SHOULD have fields to describe the characteristics of
   the session and transaction information for the packet such as the
   SN.

   First indicate this packet is the first packet of the session,
   obviously, it indicate this packet is the Request.


Tan                   Expires December 22, 2016             [Page 16]

Internet-Draft        Proactive Routing Network             June 2016


   Last indicate this packet is the last packet one side sending to
   the other side, normally it is the last packet of Data Flow.

   The detail formation of SD is TBD.

4.5.2. SRL

   SRL field is OPTIONAL, the packet have SRL field only when the SRL
   flag in SD field is true. SRL is an ordered list of label similar
   to the label stack for MPLS, of which each label includes an ID
   representing a Local Pipe and a reused number to indicate how many
   hops left using it to find the Local Pipe.

   The detail formation of SRL is TBD.

4.5.3. RPI

   RPI field is OPTIONAL, the packet have SRL field only when the RPI
   flag in SD field is true. RPI is an ordered list of Local Pipe
   information records.

   The detail formation of RPI is TBD.

4.5.4. QOS

   QOS field is OPTIONAL, the packet have QOS field only when the QOS
   flag in SD field is true. QOS describe the requirements for
   network from application and the Exception Handler.

   The detail formation of QOS is TBD.

5. Other Considerations

   The keyword of PRN is the Proactive comparison with the Reactive
   of conventional network(s). Conventional network process is
   triggered by the arriving of packet, including addressing,
   analyzing, schedule and edition, and the users have to reactively
   shape their traffic according to the network state. On the other
   side, PRN preprocess according to the user's requirements
   including addressing, analyzing and assembles the packet edition
   command in advance, reserves resource and schedules the task in
   advance, and the user can Proactively shape the traffic because
   the Pipe is visible.

   Clearly, PRN is fundamentally different with conventional
   network(s), so some issue MUST be consider carefully, including
   Scalability, Resiliency and Evolution.

5.1. Scalability

   This issue is mainly about the following aspects:


Tan                   Expires December 22, 2016             [Page 17]

Internet-Draft        Proactive Routing Network             June 2016


   o  The number of Local Pipes in a PRN.

   o  The processing overhead to create Local Pipe and reconfigure
      it.

   o  The depth of the SRL.

5.1.1. Number of Local Pipe

   For Best-Effort or DiffServ model, a Local Pipe can be shared by
   different sessions, therefore, the number of Local Pipes is the
   same order of the number of interfaces for a PRN Node.

   For IntServ model, even though one Local Pipe allocated for each
   session, the number of Local Pipes is limited because PRN only
   service the ACTIVE sessions. If a PRN node is overload, its
   Previous Hop can select another Next Hop to forward the Request,
   so a PRN Node do not have to support so much Local Pipes beyond
   its capacity.

5.1.2. Processing Overhead

   PRN node have extra procession for Request packet, including
   creating Local Pipe, checking the related resources, and inserting
   RPI into packet.

   By experience, the extra procession is similar to MAC Learning if
   the session haven't too complicated QOS demand, and in general it
   happens only once at the begin of a session. However, the
   Processing Overhead cannot be ignored if there are too many
   sessions arriving or too many reconfiguration request in a short
   time.

5.1.3. Depth of SRL

   In principle, the Depth of SRL is equal to the number of Local
   Pipes of the E2E Pipe, in other words it is linear with the
   diameter of the network.

   If the Local Pipe shared by different sessions, then there have
   the chance to reuse the label advertised by the Previous Hop,
   ideally there can be only one label for E2E Pipe, However there is
   no mechanism to promise each label can be reused.

   If the E2E Pipe have one separate Local Pipe or have one label
   exclusively on a PRN Node, the PRN node can always save the label
   advertised by the Previous Hop in local table and advertise its
   own label by which it can recover the saved label, so there can be
   only one label for E2E Pipe always.




Tan                   Expires December 22, 2016             [Page 18]

Internet-Draft        Proactive Routing Network             June 2016


5.2. Resiliency

   This document introduced two ways to enhance PRN resiliency, as
   described in Path Exploration.

   There should be furfure study about it.

5.3. Evolution

   TBD.

6. Use Cases

   TBD.

7. Security Considerations

   TBD.

8. IANA Considerations

   TBD.

9. Conclusions

   TBD.

10. References

10.1. Normative References

   [RFC3031] Rosen, E., Viswanathan, A., and Callon, R.,
             "Multiprotocol Label Switching Architecture",
             <https://datatracker.ietf.org/doc/rfc3031/>.

   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
             V., Swallow, G., "Extensions to RSVP for LSP Tunnels",
             <https://datatracker.ietf.org/doc/rfc3209/>.

   [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., Van den
             Bosch, S., "NSIS Framework",
             <https://datatracker.ietf.org/doc/rfc4080/>.

   [RFC4094] Manner, J., Fu, X., "Analysis of QoS Signaling
             ", <https://datatracker.ietf.org/doc/rfc4094/>.

   [RFC4984] Meyer, D., Zhang, L., Fall, K., (Editors), "IAB Workshop
             on Routing & Addressing",
             <https://datatracker.ietf.org/doc/rfc4984/>.




Tan                   Expires December 22, 2016             [Page 19]

Internet-Draft        Proactive Routing Network             June 2016


   [RFC7855] Previdi, S., Filsfils, C., (Editors), "SPRING Problem
             Statement", <https://datatracker.ietf.org/doc/rfc7855/>.



10.2. Informative References

   [I-D.filsfils-spring-segment-routing]  Filsfils, C., Previdi, S.,
             (Editors), "Segment Routing",
             <https://datatracker.ietf.org/doc/draft-ietf-spring-
             segment-routing/>.

   [I-D.ietf-detnet-problem-statement] Finn, N., Thubert, P.,
             "Deterministic Networking Problem Statement",
             <https://datatracker.ietf.org/doc/draft-ietf-detnet-
             problem-statement/>.

   [I-D.finn-detnet-architecture]   Finn, N., Thubert, P., Johas
             Teener, M., "Deterministic Networking Architecture",
             <https://datatracker.ietf.org/doc/draft-finn-detnet-
             architecture/>.



11. Acknowledgments

   I would like to thank Tu Boyan, Li Guoping, Jiang Sheng, Liu Bing
   and He Zijian for their various contribution with this work.

























Tan                   Expires December 22, 2016             [Page 20]

Internet-Draft        Proactive Routing Network             June 2016


Authors' Addresses

   Xuefei Tan
   Huawei Technologies
   Huawei Campus., No.156 Beiqing Rd.
   Beijing 100095
   China

   Email: tanxuefei@huawei.com












































Tan                   Expires December 22, 2016             [Page 21]