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 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", . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "Extensions to RSVP for LSP Tunnels", . [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., Van den Bosch, S., "NSIS Framework", . [RFC4094] Manner, J., Fu, X., "Analysis of QoS Signaling ", . [RFC4984] Meyer, D., Zhang, L., Fall, K., (Editors), "IAB Workshop on Routing & Addressing", . Tan Expires December 22, 2016 [Page 19] Internet-Draft Proactive Routing Network June 2016 [RFC7855] Previdi, S., Filsfils, C., (Editors), "SPRING Problem Statement", . 10.2. Informative References [I-D.filsfils-spring-segment-routing] Filsfils, C., Previdi, S., (Editors), "Segment Routing", . [I-D.ietf-detnet-problem-statement] Finn, N., Thubert, P., "Deterministic Networking Problem Statement", . [I-D.finn-detnet-architecture] Finn, N., Thubert, P., Johas Teener, M., "Deterministic Networking 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]