idnits 2.17.1 draft-jiang-service-oriented-ip-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 May 2020) is 1440 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-troan-6man-universal-ra-option-02 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: 16 November 2020 Huawei Technologies Co., Ltd 6 G. Li 7 Huawei Technologies 8 15 May 2020 10 Service Oriented Internet Protocol 11 draft-jiang-service-oriented-ip-03 13 Abstract 15 This document proposes a new, backwards-compatible, approach to 16 packet forwarding, where the service required rather than the IP 17 address required acts as the vector for routing packets at the edge 18 of the network. Deeper in the network, the mechanism can interface 19 to conventional and future methods of service or application aware 20 networking. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 16 November 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Coexistence Issues . . . . . . . . . . . . . . . . . . . . . 8 58 4. Some Usage Examples . . . . . . . . . . . . . . . . . . . . . 8 59 5. Continuity with the Existing Internet . . . . . . . . . . . . 9 60 6. Interface with Service and Application Domains . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Appendix A. Possible TLV and CBOR Encodings . . . . . . . . . . 11 65 A.1. TLV Mapping . . . . . . . . . . . . . . . . . . . . . . . 11 66 A.2. CBOR Mapping . . . . . . . . . . . . . . . . . . . . . . 13 67 Appendix B. Change log [RFC Editor: Please remove] . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 An important aspect of the Internet today is that it is no longer a 73 uniform space with uniform requirements. For both technical and 74 economic reasons, we see an emerging trend of usage scenarios that 75 are confined to some form of limited domain, and which inevitably 76 lead to applications and protocols that are only suitable within a 77 given scope [I-D.carpenter-limited-domains]. In particular, various 78 techniques have emerged for packet treatments that are specific to a 79 type of application or service. This trend collides immediately with 80 two factors: the original design concept of an Internet with end to 81 end IP transparency (such that any locally defined protocol running 82 over IP is almost certain to escape the local network), and with the 83 increasing presence of middleboxes. In this emerging context, where 84 end to end IP service is no longer a safe assumption, and where there 85 is increasing demand for specific services, this document proposes a 86 new, backwards-compatible, approach to packet forwarding, where the 87 service required rather than the IP address required acts as the 88 vector for routing packets at the edge of the network, close to the 89 host requiring a particular service or application. This form of 90 service based packet forwarding is referred to as Service Oriented IP 91 (SOIP). 93 We propose an addition to the existing core function of the network, 94 which is reachability over IPv6 or IPv4. Today, IP is focussed on 95 reachability, using best effort forwarding both to find a route and 96 to automatically share transmission resources in a simple and low- 97 cost way. As a result, transport protocols such as TCP and UDP learn 98 little or nothing about the network, beyond congestion or loss 99 signals. Several ISPs may lie on the path between a user and a 100 server, but they are largely ignorant about the services a user 101 requires. Typical services could be streamed content, regular 102 content, user posting, storage access, or calculation, but this list 103 is not exclusive. 105 Both service providers and users will benefit if a packet stream can 106 be identified intrinsically as requiring a certain kind of service. 107 This is particularly applicable for edge networks, such as those 108 supported by 5G technology, where there is an emphasis on upper layer 109 service provision. Whatever the business model - for example the ISP 110 operates all types of service, or the ISP operates no user services 111 at all and has contracts with specific service providers, or the ISP 112 is agnostic about user services - SOIP will allow for optimised 113 packet delivery. The ISP will have the choice to provide some or all 114 services. The user will have the choice to use ISP services or 115 bypass them. Traffic that leaves the domain where SOIP is in use 116 will be perfectly normal IPv6 or IPv4 traffic, sent by an exit node 117 acting as a proxy (not an IP-layer translator) for the user. 118 Additionally, IPv6 and IPv4 will be modelled as services available to 119 the user, thereby giving continuity of access to everything the user 120 has today. This is a logical extension of a principle already 121 adopted to model IPv4 as a service available via IPv6 [RFC8585]. 123 As new service and application oriented features are deployed in the 124 network, SOIP will provide a seamless interface to both existing and 125 future mechanisms. Effectively it will make client hosts future- 126 proof as the network evolves. 128 2. Proposed Solution 130 NOTE: This is a preliminary draft expected to stimulate discussion, 131 so many details are not yet defined. 133 The approach is to make the service be the central component of the 134 network, from the end user's point of view. Conceptually, the user's 135 packets will be directed at a service, not at an IP host. The first 136 hop SOIP router will either forward the packets to an upstream SOIP 137 router, or immediately dispatch the session to a suitable service. 138 At least one SOIP router in a domain must be capable of acting as a 139 dispatcher. The dispatched traffic may either remain in SOIP format, 140 or be transformed by a proxy mechanism into a conventional IP-based 141 format. Figure 1 gives an overview, and Section 5 and Section 6 142 discuss this further. 144 ----------- ----------- 145 |End-user | <-----> | SOIP | 146 | Host | | router | 147 ----------- ----------- 148 ^ 149 | 150 v 151 -------------- ----------- ----------------- 152 | SOIP-based | | SOIP | | Unknown | 153 | services |---| router + |---| future | 154 | | |dispatcher| | services | 155 -------------- ------------ ----------------- 156 | | | 157 -------------- | | | ----------------- 158 |Traditional |____/ | \____|Segment Routing| 159 |IP services | | |services | 160 -------------- ------------ ----------------- 161 | SDN | 162 | services | 163 ------------ 165 Figure 1 167 The service actions that the network can provide are abstracted into 168 a number of classes called Service Action Types (SATs). While there 169 needs to be flexibility and extensibility, the number of service 170 action types will be limited. They will not be numerous like IP 171 protocol numbers or well-known TCP or UDP port numbers. Along with 172 the SAT, a source IPv6 address is used to identify the client system. 173 As will be seen below, the destination IPv6 address becomes optional. 174 A consequence is that the IP header and some aspects of the protocol 175 stack have to be redesigned. We will show below how this can be done 176 without disturbing most of the running network. Another consequence 177 is that the first step in processing a packet is to process the SAT, 178 not the destination address (if there is one). 180 Traditional reachability, when required, is provided by classical 181 IPv6, or by IPv4 as-a-service. 183 When an SOIP packet enters a router, it is classified at line speed 184 according to the SAT. Routing to upstream SOIP routers will be based 185 on the SAT, not on a destination IP address. Routing from a 186 dispatcher may be based on the SAT if the service required is based 187 on SOIP, or on a conventional IP address otherwise. A preliminary 188 list of SATs is shown in Figure 2, with brief descriptions: 190 ------------------------------------------------------------------ 191 | SATs | Direction | Description | 192 |----------------------------------------------------------------| 193 | IPv4 reachability| Request | IPv4 destination host | 194 | |___________| | 195 | | Response | IPv4 source host | 196 |----------------------------------------------------------------| 197 | IPv6 reachability| Request | IPv6 destination host | 198 | |___________| | 199 | | Response | IPv6 source host | 200 |----------------------------------------------------------------| 201 | Discovery Service| Request | Discover network services, e.g. | 202 | |___________| DNS, CDN. May map to IP Anycast | 203 | | Response | Content ID, service ID. | 204 | | | Or "service not available" error| 205 |----------------------------------------------------------------| 206 | Multicast Service| Request | Join multicast service for some | 207 | |___________| content, e.g. video stream | 208 | | Response | Multicast directory answers | 209 | | | request, provides m/c source. | 210 |----------------------------------------------------------------| 211 | Computation | Request | Submit task to network, with | 212 | Service | | computation type, task | 213 | |___________| descriptor and requester ID | 214 | | Response | Computation resource ID, or | 215 | | | direct result of task. | 216 | | | Or "service not available" error| 217 |----------------------------------------------------------------| 218 | Storage Service | Request | Submit/retrieve data to/from | 219 | | | network storage, with data | 220 | |___________| description and/or data ID | 221 | | Response | Storage locator, data ID. | 222 | | | Or "service not available" error| 223 |----------------------------------------------------------------| 224 | App Server | Request | To submit source code or deploy | 225 | Service | | package to application platform,| 226 | |___________| with necessary configurations. | 227 | | Response | Answer with service ID. | 228 | | | Or "service not available" error| 229 ------------------------------------------------------------------ 231 Figure 2 233 For each request there will be a corresponding response. The details 234 remain to be worked out - probably a generic response message 235 including the SAT. To allow multiple overlapping sessions, each 236 request/response sequence should have a unique ID, which will be used 237 by the SOIP dispatcher to match service responses to the appropriate 238 user session. 240 For IPv6-only networks, is expected that IPv4 reachability will be 241 provided by a solution such as 464XLAT. Also, no separate SAT is 242 needed for IPv6 to IPv4 translation. For example, if a host requests 243 IPv4 reachability but supplies an IPv6 address as its own locator, 244 NAT64 [RFC6146] is implied. 246 For the moment codes for the SATs are undefined, but they are assumed 247 to be small integers. There are two possible approaches to the 248 packet format. One is to use a traditional Type-Length-Value (TLV) 249 layout. Another is to use a more flexible encoding at the lowest 250 level, taking advantage of some form of network processor in the 251 routers. An obvious choice would be Concise Binary Object 252 Representation (CBOR) [RFC7049], which combines flexibility with 253 efficiency. In either case we could require that the first four bits 254 of the wire format are a new IP version number other than 4 or 6. An 255 alternative, at least for early experimentation, is to run SOIP over 256 UDP and IPv6. 258 Examples of both encoding choices are described below. In either 259 case, the essential content of a packet header is as follows: 261 * The SAT code (small integer) 263 * Flag bits 265 * Traffic class (as for IPv6) 267 * Session Identifier (so that sessions can be tracked regardless of 268 IP address) 270 * Hop limit (small integer) 272 * User locator (IP address or identifier) 274 * Service data length (not needed in CBOR version) 276 * Service data (length depends on SAT) 278 * Payload length (not needed in CBOR version) 280 * Payload 281 Experience with IPv4 options, and IPv6 extension headers and options, 282 has shown that new ones are very hard to deploy on an operational 283 network, and that the ones defined during the initial design are not 284 always useful. Therefore we propose that all options and extensions 285 are defined as part of the service data and are not visible as part 286 of the basic packet header, giving good flexibility. 288 We propose to include the exact equivalent of the IPv6 Traffic Class 289 [RFC8200], which can work exactly as for IPv6. In contrast, one 290 defect in the IPv6 flow label [RFC6437] is that it is different in 291 the two directions of a flow. Instead we propose a session ID that 292 is the same in both directions, which has various advantages by 293 allowing immediate session identification. 295 The flag bits provide useful indications to the routing system, if 296 set: 298 * Mobile - set if the user system is mobile 300 * Flow size (3 bits) 302 - 000 means a single packet, no flow/congestion state needed 304 - other values TBD indicate type of flow/congestion state 306 * Authenticated - set if packet authenticated (details TBD) 308 * Encrypted - set if encryption applied (details TBD) 310 Note that fragmentation is not supported. Fragmentation, and the 311 related mechanisms of MTU discovery, are a significant operational 312 problem in the current Internet [I-D.ietf-intarea-frag-fragile]. We 313 simply abolish this problem area in SOIP, which is designed for use 314 in managed networks where a single size of maximum transmission unit 315 (MTU) is available everywhere. An SOIP network will have a globally 316 defined MTU. Of course, IPv4 and IPv6 reachability services via the 317 open Internet will have to support PMTUD and fragmentation as best 318 they can, but this concerns the embedded IP packets, not the SOIP 319 packets, and will be invisible locally. 321 Appendix A outlines possible TLV and CBOR encodings of the SOIP 322 protocol. 324 3. Coexistence Issues 326 SOIP is expected to coexist with IPv6; in a sense it is a low-level 327 method of orchestrating IPv6 connections. We assume that each SOIP 328 client host has at least one IPv6 address, and that SOIP routers will 329 announce themselves using a suitable IPv6 Router Advertisement 330 extension [I-D.troan-6man-universal-ra-option]. Normally, the first- 331 hop SOIP router will be the same as the IPv6 first-hop router. 333 As a result of this, all standard management mechanisms such as 334 NETCONF may be used without further specification. Also, when a data 335 connection of any kind is established after a SOIP request/response 336 exchange, all standard transport mechanisms are available over IPv6. 337 As noted above, they are subject to the locally defined MTU as long 338 as they remain within the SOIP domain. 340 We do not define how SOIP would operate in an IPv4-only network. 342 4. Some Usage Examples 344 * Storage request (upload content): 346 - Service data identifies storage requirement (temporary/ 347 permanent, private/public, encryption, etc.) 349 - Payload identifies data (path/name.format, etc.) 351 * Storage request (download content): 353 - Service data identifies transmission requirement (streamed, 354 block, etc. and the specific transport protocol - UDP, TCP, 355 QUIC, etc. - if needed) 357 - Payload identifies data (path/name.format, etc.) 359 * Computation request 361 - Service data identifies computing requirement 363 - Payload identifies computing application 365 * Reachability request 367 - Service data gives destination IP address (or DNS name) 369 - Indication of transport protocol required (details TBD) 370 - Indication of options or extension headers required (details 371 TBD) 373 5. Continuity with the Existing Internet 375 Continuity is provided in two ways: 377 1. A user node can simply use IP completely in parallel with SOIP. 378 The network stack in the user node will simply encode the IP 379 packets as SOIP packets with the SAT for IP reachability, and a 380 SOIP dispatcher will send and receive IP packets at the SOIP 381 domain boundary. 383 2. If a service in the SOIP domain needs service from elsewhere in 384 the IP Internet to respond to a user request, it will use a 385 similar dispatcher function to do so.This could also be described 386 as a proxy mechanism. (Of course, services in interconnected 387 SOIP domains may talk to each other directly.) 389 6. Interface with Service and Application Domains 391 Various techniques are emerging for service or application specific 392 networking within operators' networks. An overview of the 393 motivations is given in [I-D.li-apn6-problem-statement-usecases], and 394 specific techniques have been defined such as Network Service Headers 395 [RFC8300] and Segment Routing [RFC8402], as well as Software-Defined 396 Networking in general [RFC7426]. A SOIP dispatcher that is aware of 397 such techniques may convert SOIP traffic into one of these 398 mechanisms, for example by encapsulation or proxying. Furthermore, 399 the model is future-proof. The dispatcher could be upgraded to 400 support unknown future service or application oriented networking 401 mechanisms, without requiring changes to SOIP clients or routers. 403 7. Security Considerations 405 It is intended that both authentication and encryption should be 406 available for all SOIP packets. However, this requires further work, 407 especially to determine whether existing mechanisms for key 408 management can be used. 410 Since clients are identified by an IPv6 address, existing layer 3 411 privacy considerations for IPv6 addresses will apply to SOIP 412 [RFC7721]. Upper layer privacy considerations will depend on the 413 service concerned. 415 8. IANA Considerations 417 This document makes no request of the IANA. 419 9. References 421 [I-D.carpenter-limited-domains] 422 Carpenter, B. and B. Liu, "Limited Domains and Internet 423 Protocols", Work in Progress, Internet-Draft, draft- 424 carpenter-limited-domains-13, 2 February 2020, 425 . 428 [I-D.ietf-intarea-frag-fragile] 429 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 430 and F. Gont, "IP Fragmentation Considered Fragile", Work 431 in Progress, Internet-Draft, draft-ietf-intarea-frag- 432 fragile-17, 30 September 2019, 433 . 436 [I-D.li-apn6-problem-statement-usecases] 437 Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Liu, C., 438 Ebisawa, K., Previdi, S., and J. Guichard, "Problem 439 Statement and Use Cases of Application-aware IPv6 440 Networking (APN6)", Work in Progress, Internet-Draft, 441 draft-li-apn6-problem-statement-usecases-01, 3 November 442 2019, . 445 [I-D.troan-6man-universal-ra-option] 446 Troan, O., "The Universal IPv6 Configuration Option 447 (experiment)", Work in Progress, Internet-Draft, draft- 448 troan-6man-universal-ra-option-02, 2 April 2020, 449 . 452 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 453 NAT64: Network Address and Protocol Translation from IPv6 454 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 455 April 2011, . 457 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 458 "IPv6 Flow Label Specification", RFC 6437, 459 DOI 10.17487/RFC6437, November 2011, 460 . 462 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 463 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 464 October 2013, . 466 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 467 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 468 Defined Networking (SDN): Layers and Architecture 469 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 470 2015, . 472 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 473 Considerations for IPv6 Address Generation Mechanisms", 474 RFC 7721, DOI 10.17487/RFC7721, March 2016, 475 . 477 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 478 (IPv6) Specification", STD 86, RFC 8200, 479 DOI 10.17487/RFC8200, July 2017, 480 . 482 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 483 "Network Service Header (NSH)", RFC 8300, 484 DOI 10.17487/RFC8300, January 2018, 485 . 487 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 488 Decraene, B., Litkowski, S., and R. Shakir, "Segment 489 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 490 July 2018, . 492 [RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima, 493 "Requirements for IPv6 Customer Edge Routers to Support 494 IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 495 2019, . 497 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 498 Definition Language (CDDL): A Notational Convention to 499 Express Concise Binary Object Representation (CBOR) and 500 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 501 June 2019, . 503 Appendix A. Possible TLV and CBOR Encodings 505 A.1. TLV Mapping 507 Figure 3 shows a possible type-length-value packet format. 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |Version|R R R R| SAT |M F F F A E R R| Traffic Class | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Session Identifier (32 bits) | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Hop Limit | | 515 +-+-+-+-+-+-+-+-+ + 516 | | 517 + + 518 | Client Locator / Identifier (128 bits) | 519 + + 520 | | 521 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | | SD length | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 524 | | 525 + Service Data (variable length) + 526 ... ... 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Payload Length | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + 530 | | 531 + Payload Data (variable length) + 532 ... ... 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 3 537 Version - IP version number TBD (not needed over UDP) 539 R - Reserved, must be zero (not needed over UDP) 541 SAT - Service Action Type code 543 M - Mobile flag 545 FFF - Flow type flags (FFF = 000 for single-packet flows; other 546 values for longer flows) 548 A - Authentication flag 550 E - Privacy (encryption) flag 552 Traffic class, exactly as for IPv6 554 Session identifier, 32-bit pseudo random number 556 Client Locator / Identifier - globally unique IPv6 address 558 A.2. CBOR Mapping 560 The packet consists of a CBOR byte string preceded by a single byte 561 (Figure 4). For example, for version 7, this byte would be 0x70. 562 This byte is not decoded as CBOR, and is not needed over UDP. 564 +-+-+-+-+-+-+-+-+ 565 |Version|R R R R| 566 +-+-+-+-+-+-+-+-+ 568 Figure 4 570 The CBOR bytes then obey the CDDL [RFC8610] specification in 571 Figure 5. 573 sat-packet = [sat, flags, traffic-class, session-id, hop-limit, 574 source, service-data, ?payload] 576 sat = 0..255 577 flags = bytes .size 1 578 traffic-class = 0..255 579 session-id = 0..4294967295 ;up to 32 bits 580 hop-limit = 0..255 581 client = ipv6-address 582 service-data = any 583 payload = any 585 ipv6-address = bytes .size 16 587 Figure 5 589 The syntax of the various service-data formats can be defined in 590 separate documents for each SAT value. 592 We assume that routers capable of handling a CBOR-based layer 3 593 protocol will exist, and will use some form of programmable network 594 processor rather than traditional ASIC or FPGA designs. This allows 595 great flexibility and software-friendly extensibility, especially of 596 the service data formats. Further investigation is needed whether 597 this is realistic. 599 Appendix B. Change log [RFC Editor: Please remove] 601 * draft-jiang-service-oriented-ip-00, 2019-05-07: 603 - Initial version 605 * draft-jiang-service-oriented-ip-01, 2019-06-21: 607 - Editorial corrections 609 * draft-jiang-service-oriented-ip-02, 2019-10-29: 611 - Added overview diagram 613 - Added discussion of dispatcher function 615 - Clarifications and editorial corrections 617 * draft-jiang-service-oriented-ip-03, 2020-05-15: 619 - Editorial corrections 621 - Converted to xml2rfc v3 623 Authors' Addresses 625 Brian Carpenter 626 The University of Auckland 627 School of Computer Science 628 University of Auckland 629 PB 92019 630 Auckland 1142 631 New Zealand 633 Email: brian.e.carpenter@gmail.com 635 Sheng Jiang 636 Huawei Technologies Co., Ltd 637 Q14, Huawei Campus, No.156 Beiqing Road 638 Hai-Dian District, Beijing, 100095 639 P.R. China 641 Email: jiangsheng@huawei.com 643 Guangpeng Li 644 Huawei Technologies 645 Q14, Huawei Campus 646 No.156 Beiqing Road 647 Hai-Dian District, Beijing 648 100095 649 P.R. China 651 Email: liguangpeng@huawei.com