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]