idnits 2.17.00 (12 Aug 2021) /tmp/idnits2396/draft-tan-rtgwg-proactive-routing-network-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 272 has weird spacing: '... be inter...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 2016) is 2159 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 269, but not defined == Unused Reference: 'RFC3031' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 948, but no explicit reference was found in the text == Unused Reference: 'RFC4080' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC4094' is defined on line 956, but no explicit reference was found in the text == Unused Reference: 'RFC7855' is defined on line 963, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-segment-routing' is defined on line 968, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-detnet-problem-statement' is defined on line 973, but no explicit reference was found in the text == Unused Reference: 'I-D.finn-detnet-architecture' is defined on line 978, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4080 ** Downref: Normative reference to an Informational RFC: RFC 4094 ** Downref: Normative reference to an Informational RFC: RFC 4984 ** Downref: Normative reference to an Informational RFC: RFC 7855 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == Outdated reference: draft-ietf-detnet-problem-statement has been published as RFC 8557 Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Tan 2 Internet Draft Huawei Technologies 3 Intended status: Standard Track June 22, 2016 4 Expires: December 2016 6 Proactive Routing Network Architecture 7 draft-tan-rtgwg-proactive-routing-network-arch-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may not be 16 modified, and derivative works of it may not be created, and it 17 may not be published except as an Internet-Draft. 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be 21 modified, and derivative works of it may not be created, except to 22 publish it as an RFC and to translate it into languages other than 23 English. 25 This document may contain material from IETF Documents or IETF 26 Contributions published or made publicly available before November 27 10, 2008. The person(s) controlling the copyright in some of this 28 material may not have granted the IETF Trust the right to allow 29 modifications of such material outside the IETF Standards Process. 30 Without obtaining an adequate license from the person(s) 31 controlling the copyright in such materials, this document may not 32 be modified outside the IETF Standards Process, and derivative 33 works of it may not be created outside the IETF Standards Process, 34 except to format it for publication as an RFC or to translate it 35 into languages other than English. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other 44 documents at any time. It is inappropriate to use Internet-Drafts 45 as reference material or to cite them other than as "work in 46 progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 This Internet-Draft will expire on December 22, 2016. 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with 75 respect to this document. 77 Abstract 79 Proactive Routing Network (PRN), which runs on conventional 80 network, is user and service experience oriented; and provides a 81 set of E2E Pipes for the two End Systems of communication named 82 Requester and Source. The E2E Pipe have deterministic path learned 83 from the trace of the Request sent by Requester, and is QOS 84 guaranteed by resource reservation. Addressing issue is solved by 85 recording the labeled interfaces or Local Pipes taken along with 86 the Request to the Source. Each Pipe is protocol oblivious, 87 application aware, elastic and visible for users and operators. 89 PRN is not a new network, rather, it is a service attached to the 90 conventional network. Therefore it does not affect the operation 91 business of the conventional networks, so it is very conducive to 92 the deployment and smooth evolution. 94 PRN is valuable for users who want deterministic network service, 95 and is helpful for operators to simplify the service management 96 and easy for fault location and billing, and is helpful for 97 vendors to solve the addressing issue which is one of the biggest 98 challenges of increasing device throughput at a reasonable cost. 100 Table of Contents 102 1. Introduction.................................................. 3 103 1.1. Background............................................... 4 104 1.2. PRN...................................................... 4 105 2. Conventions used in this document............................. 6 106 3. Terminology................................................... 6 107 4. Proactive Routing Network Architecture........................ 7 108 4.1. Overview................................................. 7 109 4.2. Session Model............................................ 7 110 4.2.1. Session Description................................. 9 111 4.2.2. QOS Requirement..................................... 9 112 4.2.3. Capacity & Status Advertisement..................... 9 113 4.2.4. Exception Handling................................. 10 114 4.3. Network Model........................................... 10 115 4.3.1. Session Awareness.................................. 11 116 4.3.2. Proactive Routing.................................. 12 117 4.3.3. Path Exploration................................... 14 118 4.3.4. Source Route Forwarding............................ 15 119 4.4. Application & Service Model............................. 15 120 4.4.1. Application Model.................................. 15 121 4.4.2. QOS Model.......................................... 16 122 4.4.3. OAM Model.......................................... 16 123 4.5. Protocol Model.......................................... 16 124 4.5.1. SD................................................. 16 125 4.5.2. SRL................................................ 17 126 4.5.3. RPI................................................ 17 127 4.5.4. QOS................................................ 17 128 5. Other Considerations......................................... 17 129 5.1. Scalability............................................. 17 130 5.1.1. Number of Local Pipe............................... 18 131 5.1.2. Processing Overhead................................ 18 132 5.1.3. Depth of SRL....................................... 18 133 5.2. Resiliency.............................................. 19 134 5.3. Evolution............................................... 19 135 6. Use Cases.................................................... 19 136 7. Security Considerations...................................... 19 137 8. IANA Considerations.......................................... 19 138 9. Conclusions.................................................. 19 139 10. References.................................................. 19 140 10.1. Normative References................................... 19 141 10.2. Informative References................................. 20 142 11. Acknowledgments............................................. 20 144 1. Introduction 146 Proactive Routing Network (PRN), which runs on conventional 147 network, is user and service experience oriented; and provides a 148 set of E2E Pipes for the two End Systems of communication named 149 Requester and Source. Requester ask for data from the Source by 150 Request in PRN. The E2E Pipe have deterministic path learned from 151 the trace of the Request by Source Route, and QOS guaranteed by 152 resource reservation. Addressing issue is solved by recording the 153 labeled interfaces or Local Pipes taken along with the Request to 154 the Source. Each Pipe is protocol oblivious, application aware, 155 elastic and visible for users and operators. 157 PRN is aimed at resolving the scalability problem caused by 158 addressing issue as described in RFC4984[RFC4984]. With QoS 159 Signaling mechanisms, PRN can provides deterministic network 160 service for users especially for the application requiring ultra- 161 high through-put and ultra-low delay such as VR. Obviously, PRN is 162 helpful for operators to simplify the service management and easy 163 for fault location and billing. 165 So far, PRN applies only to point to point and connection oriented 166 communication. For point to multipoint or connectionless 167 communication, further study is needed. 169 1.1. Background 171 The global information and communication industry is evolving very 172 fast. Various internet business growing very fast. New 173 applications and fast growing internet business promote the coming 174 of the BIG data era. The "BIG" represents in the following 175 aspects: 177 BIG traffic volume: Big video and cloud computing etc. increase 178 the network traffic greatly. It is expected that the throughput of 179 core router will be required to reach to 1P by 2025. 181 BIG scale: The network boundary is expanded greatly by a lot of 182 factors, such as IOT, IPV6, etc. It is expected that the physical 183 connection of internet will reach to 100 billion by 2025. 185 BIG range of applications: Network applications not limited to 186 Web, eMail and Telnet etc. Big video such as VR, the bandwidth 187 killer application, and many industrial applications bring great 188 challenges to network architecture, including ultra-high 189 throughput, strict controlled delay and jitter, explicit and 190 stable forwarding path and forwarding behavior, etc. 192 In a nutshell, the challenge of the network especially for 193 operators and vendors is BIG. 195 1.2. PRN 197 As shown the figure below, the Requester send a Request to the 198 Source via the network, as the response, the Source send the 199 requested data back to the Requester. 201 o---------o 202 | |---------------------o 203 | Source |>>>>>>>>>>>>>>>>>>v | 204 o---------o v | 205 | Local Pipe 4 v | 206 | v | 207 | v | 208 | v | 209 | v | 210 o---------o o---------o 211 | R | | R | 212 | 2 |-------------| 1 |-----(SubNetwork x) 213 o---------o o-v-------o 214 | v | 215 | Local Pipe 3 v | 216 | v | 217 | v | 218 | v | 219 o---------o o---------o 220 | R | | R | 221 | 3 |-------------| 4 |-----(SubNetwork y) 222 o---------o o-v-------o 223 v | 224 Local Pipe 2 v | 225 v | 226 v | 227 v | 228 o---------o Local Pipe 1 o---------o 229 | | <<<<<<<<<<<<<<<< R | 230 |Requester|----------------| 5 | 231 o---------o o---------o 233 235 The Request from the Requester go through R5, R4 and R1 and then 236 reach the Source. During this process each PRN Node create a 237 reverse Local Pipe as following steps. 239 First, R5 create the Local Pipe 1 to connect the Requester when 240 the Request arrived at R5, and forward the Request to R4 with the 241 information of Local Pipe 1. 243 Second, R4 and R1 do the same as R5 to create the Local Pipe 2 and 244 Local Pipe 3, in which the Local Pipe 2 connect to R5 and the 245 Local Pipe 3 connect to R4. 247 At last, the Request arrives at the Source, and OPTIONALLY the 248 Source create the Local Pipe 4 which is not in scope of PRN. 250 The E2E Pipe is created when the Request arrive at the Source, by 251 source routing paradigm, the Source enforces the Data Flow through 252 the E2E Pipe, that is packet flow through the Local Pipe 3, the 253 Local Pipe 2 and the Local Pipe 1 in order as shown in the above 254 figure. 256 The Local Pipe 1, 2, and 3 compose a PRN for the session triggered 257 by the Request, of course, the PRN can have more Pipes if the node 258 do multiple path exploration in the above first and second steps. 260 2. Conventions used in this document 262 In examples, "C:" and "S:" indicate lines sent by the client and 263 server respectively. 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 266 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 267 in this document are to be interpreted as described in RFC 2119 268 [RFC2119]. 270 In this document, these words will appear with that interpretation 271 only when in ALL CAPS. Lower case uses of these words are not to 272 be interpreted as carrying significance described in RFC 2119. 274 In this document, the characters ">>" preceding an indented 275 line(s) indicates a statement using the key words listed above. 276 This convention aids reviewers in quickly identifying or finding 277 the portions of this RFC covered by these keywords. 279 3. Terminology 281 PRN: Proactive Routing Network, a virtual network, and the 282 mechanism to create the network. 284 PRN node: A Node with PRN enabled. 286 End System: A terminal or host or any other which end a packet or 287 traffic. 289 Requester: An End System sending the request to data source to ask 290 for data or information. 292 Request: A packet sent by Requester, especially the first packet 293 to start a session. 295 Source: The End System sending data to the Requester in response 296 to the Request. 298 Data Flow: A stream of packets from Source to Requester. 300 Previous Hop: A PRN node on the packet network path immediately 301 before the node currently processing the packet. 303 Next Hop: A PRN node on the packet network path immediately after 304 the node currently processing the packet. 306 Local Pipe: A pipe created by a PRN node to its Previous Hop. 308 E2E Pipe: A pipe from one end system to the other end system 309 composed by an ordered list of Local Pipe. 311 Upstream Pipe: An E2E Pipe from Requester to Source. 313 Downstream Pipe: An E2E Pipe from Source to Requester. 315 SRL: Source Routing Label list, an ordered list of Local Pipe's 316 Label or Source Routing Label. 318 RPI: Reverse Path Information, an ordered list of Local Pipe 319 information or Reverse Pipe Information. 321 4. Proactive Routing Network Architecture 323 In this section, the main concepts, architecture and related 324 methods of PRN, are described. 326 4.1. Overview 328 PRN architecture includes the Basic Function Model, Application & 329 Service Model and Protocol Model. 331 The three basic functions of PRN are Conventional Network(s), 332 Session model and Network model: 334 o Conventional Network(s) is the basic operating infrastructure 335 for PRN, such as IP, MPLS and ETH network, etc. PRN does not 336 change the basic mechanism of the conventional network, but 337 have some requirements for it, such as considering more aspects 338 when select the next hop to forward Request packet. 339 Conventional network(s) does not belong to the scope of this 340 document and no further description about it. 342 o Session Model defines how a session is established in PRN 343 environment, and describes the negotiation operation between 344 End System and PRN. 346 o Network Model defines how to build, maintain and tear PRN. 348 4.2. Session Model 350 Data Model on network can be categorized as Pull Model and Push 351 Model, of which Push Model can be further classified as 352 Unsolicited Push and Solicited Push. Pull Model and Solicited Push 353 model have the common characteristic, that is, the session MUST be 354 started from the Requester by sending a Request to the data 355 Source. Unsolicited Push model is not considered currently. 357 The figure below shows the Session Model. The data Requester send 358 Request to the data Source via the network, normally, the data 359 Source segment and encapsulate the requested data into packets and 360 send back to the Requester via network. The packet stream from the 361 Source to the Requester is named Data Flow in the figure. 363 o-----------------------------------o o-------------------------o 364 | +-------------------------+ | | +-------------------+ | 365 | | Requester | | | | Source | | 366 | +-------------------------+ | | | Application Layer | | 367 | | Application Layer | | | +--x-x---x-x----x-x-+ | 368 | +-------------------------+ | | v ^ v ^ v ^ | 369 o------x-x---------x-x-----x-x------o | +-x-x--+x-x+ +x-x+ | 370 ^ | ^ | ^ | Request | | O |TCP| | P | | 371 Data Flow ^ v ^ v ^ v | | S | / | | R | | 372 o---------x-x---------x-x-----x-x---------o | | I | IP| | N | | 373 | +------------+ +-----+ +-----+ | | +----------+ | | | 374 | |Presentation| | | | | | | | Network | | | | 375 | +------------+ |Trans| | P | | | +----------+ +---+ | 376 | | Session | |port | | R | | | Data Link & Physical | 377 | +------------+ | | | N | | o----------x-x------------o 378 | | Transport | | | |Layer| | Data Flow v ^ Request 379 | +------------+-+-----+ | | | o--------x-x-----------o 380 | | Network | | | | |Network(Router/Switch)| 381 | +--------------------+ +-----+ | | +-----+ + ---- + | 382 o-------------------x-x-------------------o | | P | |IP/ETH| | 383 ^ | | | R | |/MPLS.| | 384 ^ v | | N | |Conven| | 385 o--------------x-x---------------o | |Pipe | |tional| | 386 | +-----------------------+ | | +-----+ +------+ | 387 | | Data Link | | Data Flow| +------------------+ | 388 | +-----------------------+ x <<<<<<<< x | Data Link | | 389 | | Physical | x -------> x | &Physical | | 390 | +-----------------------+ | Request | +------------------+ | 391 o--------------------------------o o----------------------o 393 Session Model 395 In addition to the traditional information such as the destination 396 address and port number to tell the Source what is requested, the 397 Request SHOULD also carry session traffic description, QOS 398 requirements, the capacity of the End System, and exception 399 handling definitions. 401 Network forward the Request to the Source, and at the same time a 402 PRN is created for the Data Flow which contains one or more E2E 403 Pipes. The Source send the Data Flow via the selected Pipe. 405 The Source can correct Session Description, adjust QOS 406 requirements or redefine Exception Handling. The modified 407 information SHOULD be carried in the Data Flow packet. PRN will 408 advertisement the newest status of the E2E Pipe when the Pipe is 409 built or changed. By this way, the Source, the Requester and the 410 PRN inform or negotiate with each other about the session and the 411 Pipe. 413 Although the negotiation process can take place at any stage of 414 the session, but generally only in the initial stage, that is only 415 the Request and the first packet of the Data Flow will carry the 416 session description and QOS information. 418 In order to make PRN Node remove the Pipe and release the related 419 resources at the end of the session, the last packet of the Data 420 Flow SHOULD carry the necessary session description and QOS 421 information. Similarly, by the end of session, the Source SHOULD 422 send a packet carrying the above necessary information on the 423 backup Pipe if have any. 425 4.2.1. Session Description 427 Session Description SHOULD accurately describes the session 428 characteristics as RSVP do, and there SHOULD have necessary 429 information to identify the packet in the session such as the 430 first or the last packet of the session. Obviously the first 431 packet is the Request triggering the PRN creation for the session 432 and the last packet will be used to tear the PRN. 434 4.2.2. QOS Requirement 436 QOS Requirement SHOULD be defined as goal oriented, so it SHOULD 437 define the effect but not the means of QOS. Generally it SHOULD 438 include the bandwidth, delay, and jitter etc., as well as the 439 minimum lever of QOS if the demand cannot be met. 441 4.2.3. Capacity & Status Advertisement 443 All the elements involved in PRN, including the End System and PRN 444 Node MUST advertise if it is PRN enabled. If the End System does 445 not support PRN, the network SHOULD select a PRN node as the proxy 446 for the session. 448 Other advertisement are OPTIONAL, if there haven't the 449 advertisement for an ability, that means the entity does not have 450 this ability; if there haven't the advertisement about a status, 451 that means the state is ok to meet the demand, without any 452 exception. 454 4.2.4. Exception Handling 456 Exception Handling defines the action when the network or the peer 457 End System have some problems to meet the requirements. Generally 458 it associated with the QOS Requirements. 460 Exception handling is OPTIONALLY given by the End System. 462 4.3. Network Model 464 Network Model includes PRN nodes and the network composed by it, 465 and the End System connected to the network. As shown in Figure 466 below, there are a PRN created for the session which is initiated 467 by the Requester to ask data from the Source. This PRN has only 468 one E2E Pipe which is composed by Local Pipe 1, Local Pipe 2 and 469 Local Pipe 3. 471 o---------o 472 | Data |---------------------o 473 | Source | | 474 o---------o>>>>>>>>>>>>>>>>>>v | 475 | Local Pipe 4 v | 476 | v | 477 | v | 478 | v | 479 | v | 480 o---------o o---------o 481 | R | | R | 482 | 2 |-------------| 1 |-----(SubNetwork x) 483 o---------o o-v-------o 484 | v | 485 | Local Pipe 3 v | 486 | v | 487 | v | 488 | v | 489 o---------o o---------o 490 | R | | R | 491 | 3 |-------------| 4 |-----(SubNetwork y) 492 o---------o o-v-------o 493 v | 494 Local Pipe 2 v | 495 v | 496 v | 497 v | 498 o---------o Local Pipe 1 o---------o 499 | Data | <<<<<<<<<<<<<<<< R | 500 |Requester|----------------| 5 | 501 o---------o o---------o 503 Network Model 505 The link connecting the End System and PRN Node or the link 506 between two PRN Nodes can be a physical link, or a virtual link 507 such as LSP or GRE tunnel by which the E2E Pipe can pass through 508 the conventional network, or a PRN E2E Pipe by which PRNs can be 509 cascaded. 511 The Request is forwarded by PRN Node hop by hop. Besides the 512 conventional forwarding process, each PRN Node intercept the 513 session information such as Session Description and QOS from the 514 Request, and create a Local Pipe to the Previous Hop. When forward 515 the Request to the Next Hop, the Local Pipe's information named 516 RPI is inserted in the Request packet. 518 The Source obtains the Local Pipes which composed the E2E Pipe 519 connecting to the Requester. As shown above, the E2E Pipe is 520 composed by the Local Pipe 1, 2, 3. The Local Pipe 4 is OPTIONALLY 521 created by the Source which is not part of the PRN. 523 The Source encapsulates the Local Pipes' label in a Source Routing 524 diagram such as SRL(Source Routing Label list). As the above 525 example, the label for Local Pipe 1, 2, 3 is 1, 2, 3, then the SRL 526 SHOULD be encoded as {3,2,1}. 528 Each PRN Node get the right label advertised by itself, then get 529 the corresponding Local Pipe from which the output interface and 530 other information can be used to process and forward the packet to 531 the next PRN Node. 533 PRN supports multiple E2E Pipes exploration by explicit request 534 from Requester or local configuration of the PRN Node. For 535 example, another E2E Pipe crossing the R2 or R3 or both can be 536 created for the PRN showed by the above figure. 538 Thus, PRN Network Model contains the following elements: Session 539 Awareness, Proactive Routing, Path Exploration and Source Route 540 Forwarding. 542 4.3.1. Session Awareness 544 PRN Node MUST cognize the first packet of a session which is the 545 so called the Request. Although there are many ways, this document 546 propose it SHOULD be explicitly flagged by the End System 547 initiating the session. 549 PRN Node MUST cognize the last packet by which the PRN Node tear 550 down the Local Pipe and release the related resources. Of course, 551 PRN node SHOULD be capable of aging the Local Pipe by detecting 552 the Data Flow's traffic. 554 PRN Node SHOULD be aware of the other information of the session 555 from packet, such as QOS by which PRN Node can make proper 556 resource reservation for the Local Pipe and take it as a key 557 consideration to select the Next Hop for the Request. 559 If the necessary information cannot be obtained from packet, PRN 560 Node SHOULD process reasonably based on well-known logic or local 561 configuration. For example, receiving a TCP_SYN packet, PRN Node 562 SHOULD be able to reasonably infer that there will be a Data Flow 563 from the server to the client, although there haven't Session 564 Description in the packet. 566 4.3.2. Proactive Routing 568 When Received a Request, PRN Node creates a Local Pipe to the 569 Previous Hop and forward the Request with the Local Pipe's 570 information to the Next Hop. This process is called Proactive 571 Routing. 573 PRN Node MUST assigns a local unique label for the Local Pipe 574 created by it, and MUST advertise the label to the Next Hop along 575 the Request. 577 Besides the label, PRN Node SHOULD advertise the other information 578 about the Local Pipe such as QOS and link attributes. The Local 579 Pipe information including the label is encoded in RPI and 580 inserted in the Request packet before which is forwarded to the 581 Next Hop. 583 A Local Pipe can have multiple labels, but one label MUST belong 584 to only one Local Pipe. The label MUST be kept unchanged once 585 assigned to a session. Label has only local significance, and the 586 PRN Node MUST be able to find the corresponding Local Pipe solely 587 by the label it advertised. 589 The other end of the Local Pipe MUST be the Previous Hop on the 590 Request path, and MUST be kept unchanged once the Local Pipe is 591 created. The Local Pipe SHOULD have other information to speed up 592 packet procession such as Packet Edition or Prepositioning. 594 PRN Node SHOULD report the status or change the Local Pipe's 595 configuration in response to the request from the End System, and 596 the information SHOULD be carried along with the packet giving the 597 request information. 599 Source obtains the RPIs advertised by the PRN Nodes, and the 600 Source MUST encapsulates the Data Flow packet with the Local 601 Pipes' label in a Source Routing format such as SRL described in 602 PRN Protocol Model in order to enforce the packet pass through the 603 Local Pipes. 605 Local Pipe can be shared by multiple Data Flows or Sessions, but 606 PRN Node SHOULD create a separate Local Pipe for a Data Flow with 607 strict QOS requirement. PRN don't make any assumption on the 608 detail mechanism for QOS but only define the effect. The PRN Node 609 MUST meet the commitment advertised in its RPI. 611 PRN Node SHOULD reuse the label advertised by the Previous Hop 612 when find a local unique label for a Local Pipe, but the method 613 about how to reuse label is not described herein. 615 If PRN Node reuse the label advertised by the Previous Hop, it 616 MUST make sure the label is locally unique and MUST tell the 617 Source through RPI. The Source SHOULD merge the labels reused by 618 different nodes to one label with the reused number. 620 PRN node SHOULD minus one the number after processing the label, 621 and delete it if the number is zero before sending the packet to 622 next hop. Obviously, PRN node can reuse only the label advertised 623 by the Previous Hop. 625 PRN Node may need to reserve resource in order to guarantee QOS. 626 The resource reservation can be done at the Local Pipe creating 627 time, or just do part of it such as assigning a output TM queue 628 for the Data Flow and left the bandwidth be reserved when the 629 first Data Flow packet arrived which SHOULD carry with the newest 630 QOS requirement. Whatever the case, PRN Node SHOULD check the 631 related resources and MUST advertise the status and the QOS 632 commitment by the Local Pipe along the Request to inform the 633 Source. 635 PRN allow the End System to inquire the pipes' information or 636 change the QOS requirement by in-band mode. PRN Node SHOULD 637 advertise the newest status of the Local Pipe whenever it is 638 changed. 640 PRN node SHOULD be able to insert the OAM information such as the 641 processing time or queuing time in RPI if the End System requests 642 or the operator demands by configuration. OAM Model latter will 643 describe the operation in detail. 645 PRN node SHOULD do as the Exception Handling defined by the End 646 System or local configuration when it is impossible to meet the 647 minimum requirements. 649 PRN node SHOULD be aware of the end of the Data Flow; As described 650 in Session Model, the Source SHOULD send a end signal when the 651 Data Flow ends, or PRN node SHOULD monitor the traffic changes of 652 the Data Flow to infer the end signal, such as if there have no 653 traffic through the Local Pipe for a time then the Local Pipe can 654 be released. 656 PRN build the Upstream Pipe transporting Data Flow from Source to 657 Requester by the Request sent from Requester to Source, similarly 658 a Downstream Pipe can be built by the Request sent from Source to 659 Requester. The Request sent from Source to Requester can be a 660 separate packet or a Data Flow packet with request information. If 661 the latter, the Upstream Pipe is exactly symmetrical with Upstream 662 Pipe and PRN node SHOULD bind the corresponding Local Pipe. If the 663 former, the process is exactly the same as the process to build 664 the Upstream Pipe, but the Source and the Requester exchange their 665 role, in this case, we can think there are two different PRNs. 667 4.3.3. Path Exploration 669 The Downstream Pipe's path is exactly symmetric with the Request 670 network path, so the process on each PRN node to choose the Next 671 Hop for the Request is the Path Exploration for the E2E Pipe. 673 There are many ways to find the Next Hop for the Request, 674 including searching FIB by DIP or MAC table by DMAC table, a SDN 675 way or SR way, etc. These basic mechanisms are out of scope of 676 PRN. 678 In addition to just considering for the Request as conventional 679 method, PRN node SHOULD check the status of the system load and 680 the link connecting to this node of the Next Hop in order to guide 681 the Data Flow arriving from the best node and link. PRN node 682 SHOULD choose the Next Hop with a link best matching the 683 requirements of the session and MUST NOT choose the Next Hop which 684 is too overloaded to create more Local Pipe. 686 PRN node SHOULD send Request to multiple qualified Next Hops when 687 the Request ask to explore multiple paths explicitly or by the 688 local configuration. When do multipath exploration, PRN MUST make 689 sure there is only one Master copy of the Request, that is when 690 the received Request is Slaver, then all the copy the PRN node 691 send to Next Hops MUST be Slaver, Otherwise, the PRN node MUST 692 mark the copies as Slaver but keep one as Master. 694 In this case, the Source may receive multiple copies of the 695 Request each of which carries a different E2E Pipe. If the Request 696 destination address is Anycast or alike, the Source MUST wait for 697 the Master before collecting and selecting the E2E Pipe(s) from 698 the copies, then responds the Requester and send the Data Flow to 699 it by the selected E2E Pipe(s). 701 PRN Node SHOULD be able to intercept the RPI information from the 702 received Requests, and learn from it to get the backup Local Pipe 703 sequences which can arrive the same Local Pipe of a PRN Node. When 704 the PRN Node detect some faults on a downstream Local Pipe 705 (normally the Local Pipe created by itself), it can do Local Path 706 Repair for the packet to bypass the faulty Local Pipe. 708 4.3.4. Source Route Forwarding 710 The Source collect the RPIs from each Request copy, and send Data 711 Flow to the Requester through one or more Downstream Pipes which 712 is selected by the Source independently according to the 713 information carried in RPIs. 715 Each E2E Pipe is represented by an ordered label list, and the 716 Source MUST take it with the Data Flow packet to enforce the 717 packet through the dedicated Local Pipes in order. 719 Source Routing or Explicit Routing can have many forms, such as 720 the forms proposed by SR. PRN propose the PRN form which will be 721 described in Protocol Model. 723 4.4. Application & Service Model 725 PRN provides deterministic, protocol oblivious, application aware, 726 elastic and visible E2E Pipe for users. 728 Deterministic, means the path of the E2E Pipe is fixed or pinned 729 during the whole lifetime of the session, and can have 730 deterministic or predictable delay and jitter. 732 Protocol Oblivious, means the payload transported in the E2E Pipe 733 can be anything even a structured bit stream. 735 Application aware, means each PRN Node can be aware of the 736 requirements from application, Local Pipe and E2E Pipe can be at 737 application or flow grain. 739 Elastic, means the QOS can be absolutely guaranteed, and can also 740 be adaptive according to the network state under user permission, 741 and user have the flexibility to use the E2E Pipes or the Local 742 Pipes freely by Source Routing. 744 Visible, means E2E Pipe and Local Pipe is visible to user and 745 operator, the path is deterministic, the status and the attribute 746 of each Local Pipe are advertised by RPI to user and operator. 748 Application Model, QOS and OAM model are described below, each 749 give some examples of using PRN to satisfy different applications. 751 4.4.1. Application Model 753 As described above, currently PRN does not support Unsolicited 754 Push data model, and PRN cannot promise zero packet loss ratio, so 755 PRN MUST cooperate with other mechanism to make reliable 756 transaction such as TCP acknowledgement mechanism or 1+1 757 protection mechanism which is out of scope of PRN. 759 Solicited Push Model 761 TBD. 763 Unidirectional Pull Model 765 TBD. 767 Bidirectional Pull Model 769 TBD. 771 4.4.2. QOS Model 773 TBD. 775 4.4.3. OAM Model 777 TBD. 779 4.5. Protocol Model 781 This document propose a new protocol layer, the PRN layer, as 782 shown in the following figure. 784 +---------+----------+----------------------+ 785 | Layer 2 | PRN | Data(Optional L3/L4) | 786 +---------+----------+----------------------+ 788 Protocol Model 790 PRN layer is between the Layer 2 and the Layer 3, as described in 791 Session Model, PRN layer can interact directly with application 792 layer and have network path information, so the Layer 3 and Layer 793 4 is optional once the PRN is created. 795 There MUST have a new protocol ID in Layer 2 header to indicate 796 PRN layer is followed. IANA section describe this issue. 798 PRN layer contains SD, SRL, RPI and QOS fields, not all fields are 799 required for any packet in a session. 801 4.5.1. SD 803 SD, Session Description. It MUST have First, Last, SRL, RPI, QOS 804 flags. SD SHOULD have fields to describe the characteristics of 805 the session and transaction information for the packet such as the 806 SN. 808 First indicate this packet is the first packet of the session, 809 obviously, it indicate this packet is the Request. 811 Last indicate this packet is the last packet one side sending to 812 the other side, normally it is the last packet of Data Flow. 814 The detail formation of SD is TBD. 816 4.5.2. SRL 818 SRL field is OPTIONAL, the packet have SRL field only when the SRL 819 flag in SD field is true. SRL is an ordered list of label similar 820 to the label stack for MPLS, of which each label includes an ID 821 representing a Local Pipe and a reused number to indicate how many 822 hops left using it to find the Local Pipe. 824 The detail formation of SRL is TBD. 826 4.5.3. RPI 828 RPI field is OPTIONAL, the packet have SRL field only when the RPI 829 flag in SD field is true. RPI is an ordered list of Local Pipe 830 information records. 832 The detail formation of RPI is TBD. 834 4.5.4. QOS 836 QOS field is OPTIONAL, the packet have QOS field only when the QOS 837 flag in SD field is true. QOS describe the requirements for 838 network from application and the Exception Handler. 840 The detail formation of QOS is TBD. 842 5. Other Considerations 844 The keyword of PRN is the Proactive comparison with the Reactive 845 of conventional network(s). Conventional network process is 846 triggered by the arriving of packet, including addressing, 847 analyzing, schedule and edition, and the users have to reactively 848 shape their traffic according to the network state. On the other 849 side, PRN preprocess according to the user's requirements 850 including addressing, analyzing and assembles the packet edition 851 command in advance, reserves resource and schedules the task in 852 advance, and the user can Proactively shape the traffic because 853 the Pipe is visible. 855 Clearly, PRN is fundamentally different with conventional 856 network(s), so some issue MUST be consider carefully, including 857 Scalability, Resiliency and Evolution. 859 5.1. Scalability 861 This issue is mainly about the following aspects: 863 o The number of Local Pipes in a PRN. 865 o The processing overhead to create Local Pipe and reconfigure 866 it. 868 o The depth of the SRL. 870 5.1.1. Number of Local Pipe 872 For Best-Effort or DiffServ model, a Local Pipe can be shared by 873 different sessions, therefore, the number of Local Pipes is the 874 same order of the number of interfaces for a PRN Node. 876 For IntServ model, even though one Local Pipe allocated for each 877 session, the number of Local Pipes is limited because PRN only 878 service the ACTIVE sessions. If a PRN node is overload, its 879 Previous Hop can select another Next Hop to forward the Request, 880 so a PRN Node do not have to support so much Local Pipes beyond 881 its capacity. 883 5.1.2. Processing Overhead 885 PRN node have extra procession for Request packet, including 886 creating Local Pipe, checking the related resources, and inserting 887 RPI into packet. 889 By experience, the extra procession is similar to MAC Learning if 890 the session haven't too complicated QOS demand, and in general it 891 happens only once at the begin of a session. However, the 892 Processing Overhead cannot be ignored if there are too many 893 sessions arriving or too many reconfiguration request in a short 894 time. 896 5.1.3. Depth of SRL 898 In principle, the Depth of SRL is equal to the number of Local 899 Pipes of the E2E Pipe, in other words it is linear with the 900 diameter of the network. 902 If the Local Pipe shared by different sessions, then there have 903 the chance to reuse the label advertised by the Previous Hop, 904 ideally there can be only one label for E2E Pipe, However there is 905 no mechanism to promise each label can be reused. 907 If the E2E Pipe have one separate Local Pipe or have one label 908 exclusively on a PRN Node, the PRN node can always save the label 909 advertised by the Previous Hop in local table and advertise its 910 own label by which it can recover the saved label, so there can be 911 only one label for E2E Pipe always. 913 5.2. Resiliency 915 This document introduced two ways to enhance PRN resiliency, as 916 described in Path Exploration. 918 There should be furfure study about it. 920 5.3. Evolution 922 TBD. 924 6. Use Cases 926 TBD. 928 7. Security Considerations 930 TBD. 932 8. IANA Considerations 934 TBD. 936 9. Conclusions 938 TBD. 940 10. References 942 10.1. Normative References 944 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., 945 "Multiprotocol Label Switching Architecture", 946 . 948 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 949 V., Swallow, G., "Extensions to RSVP for LSP Tunnels", 950 . 952 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., Van den 953 Bosch, S., "NSIS Framework", 954 . 956 [RFC4094] Manner, J., Fu, X., "Analysis of QoS Signaling 957 ", . 959 [RFC4984] Meyer, D., Zhang, L., Fall, K., (Editors), "IAB Workshop 960 on Routing & Addressing", 961 . 963 [RFC7855] Previdi, S., Filsfils, C., (Editors), "SPRING Problem 964 Statement", . 966 10.2. Informative References 968 [I-D.filsfils-spring-segment-routing] Filsfils, C., Previdi, S., 969 (Editors), "Segment Routing", 970 . 973 [I-D.ietf-detnet-problem-statement] Finn, N., Thubert, P., 974 "Deterministic Networking Problem Statement", 975 . 978 [I-D.finn-detnet-architecture] Finn, N., Thubert, P., Johas 979 Teener, M., "Deterministic Networking Architecture", 980 . 983 11. Acknowledgments 985 I would like to thank Tu Boyan, Li Guoping, Jiang Sheng, Liu Bing 986 and He Zijian for their various contribution with this work. 988 Authors' Addresses 990 Xuefei Tan 991 Huawei Technologies 992 Huawei Campus., No.156 Beiqing Rd. 993 Beijing 100095 994 China 996 Email: tanxuefei@huawei.com