idnits 2.17.1 draft-jiang-service-oriented-ip-00.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 (May 7, 2019) is 1813 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-carpenter-limited-domains-07 == Outdated reference: A later version (-17) exists of draft-ietf-intarea-frag-fragile-09 == Outdated reference: A later version (-06) exists of draft-troan-6man-universal-ra-option-01 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: November 8, 2019 Huawei Technologies Co., Ltd 6 G. Li 7 Huawei Technologies 8 May 7, 2019 10 Service Oriented Internet Protocol 11 draft-jiang-service-oriented-ip-00 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. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 8, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Coexistence Issues . . . . . . . . . . . . . . . . . . . . . 6 57 4. Some Usage Examples . . . . . . . . . . . . . . . . . . . . . 7 58 5. Continuity with the Existing Internet . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 Appendix A. Possible TLV and CBOR Encodings . . . . . . . . . . 9 63 A.1. TLV Mapping . . . . . . . . . . . . . . . . . . . . . . . 9 64 A.2. CBOR Mapping . . . . . . . . . . . . . . . . . . . . . . 10 65 Appendix B. Change log [RFC Editor: Please remove] . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 An important aspect of the Internet today is that it is no longer a 71 uniform space with uniform requirements. For both technical and 72 economic reasons, we see an emerging trend of usage scenarios that 73 are confined to some form of limited domain, and which inevitably 74 lead to applications and protocols that are only suitable within a 75 given scope [I-D.carpenter-limited-domains]. This trend collides 76 immediately with two factors: the original design concept of an 77 Internet with end to end IP transparency (such that any locally 78 defined protocol running over IP is almost certain to escape the 79 local network), and with the increasing presence of interfering 80 middleboxes. In this emerging context, where end to end IP service 81 is no longer a safe assumption, and where there is increasing demand 82 for specific services, this document proposes a new, backwards- 83 compatible, approach to packet forwarding, where the service required 84 rather than the IP address required acts as the vector for routing 85 packets at the edge of the network. This is known as Service Based 86 Packet Forwarding (SBPF) or Service Oriented IP (SOIP). 88 We propose an addition to the existing core function of the network, 89 which is reachability over IPv6 or IPv4. Today, IP is focussed on 90 reachability, using best effort forwarding both to find a route and 91 to automatically share transmission resources in a simple and low- 92 cost way. As a result, transport protocols such as TCP and UDP learn 93 little or nothing about the network, beyond congestion or loss 94 signals. Several ISPs may lie on the path between a user and a 95 server, but they are largely ignorant about the services a user 96 requires. Typical services could be streamed content, regular 97 content, user posting, storage access, or calculation, but this list 98 is not exclusive. 100 Both service providers and users will benefit if a packet stream can 101 be identified intrinsically as requiring a certain kind of service. 102 Whatever the business model - for example the ISP operates all types 103 of service, or the ISP operates no user services at all and has 104 contracts with specific service providers, or the ISP is agnostic 105 about user services - SOIP will allow for optimised packet delivery. 106 The ISP will have the choice to provide some or all services. The 107 user will have the choice to use ISP services or bypass them. 108 Traffic that leaves the domain where SOIP is in use will be perfectly 109 normal IPv6 or IPv4 traffic, sent by an exit node acting as a proxy 110 (not an IP-layer translator) for the user. Additionally, IPv6 and 111 IPv4 will be modelled as services available to the user, thereby 112 giving continuity of access to everything the user has today. This 113 is a logical extension of a principle already adopted to model IPv4 114 as a service available via IPv6 [RFC8585]. 116 2. Proposed Solution 118 NOTE: This is a preliminary draft expected to stimulate discussion, 119 so many details are not yet defined. 121 The approach is to make the service be the central component of the 122 network. Conceptually, the user's packets will be directed at a 123 service, not at an IP host. 125 The service actions that the network can provide are abstracted into 126 a number of classes called Service Action Types (SATs). While there 127 needs to be flexibility and extensibility, the number of service 128 action types will be limited. They will not be numerous like IP 129 protocol numbers or well-known TCP or UDP port numbers. Along with 130 the SAT, a source IPv6 address is used to identify the client system. 131 As will be seen below, the destination IPv6 address becomes optional. 132 A consequence is that the IP header and some aspects of the protocol 133 stack have to be redesigned. We will show below how this can be done 134 without disturbing most of the running network. Another consequence 135 is that the first step in processing a packet is to process the SAT, 136 not the destination address (if there is one). 138 Traditional reachability, when required, is provided by classical 139 IPv6, or by IPv4 as-a-service. 141 When an SOIP packet enters a router, it is classified at line speed 142 according to the SAT. A preliminary list of SATs is shown in 143 Figure 1, with brief descriptions: 145 ------------------------------------------------------------------ 146 | SATs | Direction | Description | 147 |----------------------------------------------------------------| 148 | IPv4 reachability| Request | IPv4 destination host | 149 | |___________| | 150 | | Response | IPv4 source host | 151 |----------------------------------------------------------------| 152 | IPv6 reachability| Request | IPv6 destination host | 153 | |___________| | 154 | | Response | IPv6 source host | 155 |----------------------------------------------------------------| 156 | Discovery Service| Request | Discover network services, e.g. | 157 | |___________| DNS, CDN. May map to IP Anycast | 158 | | Response | Content ID, service ID. | 159 | | | Or "service not available" error| 160 |----------------------------------------------------------------| 161 | Multicast Service| Request | Join multicast service for some | 162 | |___________| content, e.g. video stream | 163 | | Response | Multicast directory answers | 164 | | | request, provides m/c source. | 165 |----------------------------------------------------------------| 166 | Computation | Request | Submit task to network, with | 167 | Service | | computation type, task | 168 | |___________| descriptor and requester ID | 169 | | Response | Computation resource ID, or | 170 | | | direct result of task. | 171 | | | Or "service not available" error| 172 |----------------------------------------------------------------| 173 | Storage Service | Request | Submit/retrieve data to/from | 174 | | | network storage, with data | 175 | |___________| description and/or data ID | 176 | | Response | Storage locator, data ID. | 177 | | | Or "service not available" error| 178 |----------------------------------------------------------------| 179 | App Server | Request | To submit source code or deploy | 180 | Service | | package to application platform,| 181 | |___________| with necessary configurations. | 182 | | Response | Answer with service ID. | 183 | | | Or "service not available" error| 184 ------------------------------------------------------------------ 186 Figure 1 188 For each request there will be a corresponding response. The details 189 remain to be worked out - probably a generic response message 190 including the SAT. To allow multiple overlapping sessions, each 191 request/response sequence should have a unique ID. 193 For IPv6-only networks, is expected that IPv4 reachability will be 194 provided by a solution such as 464XLAT. Also, no separate SAT is 195 needed for IPv6 to IPv4 translation. For example, if a host requests 196 IPv4 reachability but supplies an IPv6 address as its own locator, 197 NAT64 is implied. 199 For the moment codes for the SATs are undefined, but they are assumed 200 to be small integers. There are two possible approaches to the 201 packet format. One is to use a traditional Type-Length-Value (TLV) 202 layout. Another is to use a more flexible encoding at the lowest 203 level, taking advantage of some form of network processor in the 204 routers. An obvious choice would be Concise Binary Object 205 Representation (CBOR) [RFC7049], which combines flexibility with 206 efficiency. In either case we could require that the first four bits 207 of the wire format are a new IP version number other than 4 or 6. An 208 alternative, at least for early experimentation, is to run SOIP over 209 UDP and IPv6. 211 Examples of both encoding choices are described below. In either 212 case, the essential content of a packet header is as follows: 214 o The SAT code (small integer) 216 o Flag bits 218 o Traffic class (as for IPv6) 220 o Session Identifier (so that sessions can be tracked regardless of 221 IP address) 223 o Hop limit (small integer) 225 o User locator (IP address or identifier) 227 o Service data length (not needed in CBOR version) 229 o Service data (length depends on SAT) 231 o Payload length (not needed in CBOR version) 233 o Payload 235 Experience with IPv4 options, and IPv6 extension headers and options, 236 has shown that new ones are very hard to deploy on an operational 237 network, and that the ones defined during the initial design are not 238 always useful. Therefore we propose that all options and extensions 239 are defined as part of the service data and are not visible as part 240 of the basic packet header, giving good flexibility. 242 We propose to include the exact equivalent of the IPv6 Traffic Class, 243 which can work exactly as for IPv6 and IPv4. In contrast, one defect 244 in the IPv6 flow label is that it is different in the two directions 245 of a flow. Instead we propose a session ID that is the same in both 246 directions, which has various advantages by allowing immediate 247 session identification. 249 The flag bits provide useful indications to the routing system, if 250 set: 252 o Mobile - set if the user system is mobile 254 o Flow size (3 bits) 256 * 000 means a single packet, no flow/congestion state needed 258 * other values TBD indicate type of flow/congestion state 260 o Authenticated - set if packet authenticated (details TBD) 262 o Encrypted - set if encryption applied (details TBD) 264 Note that fragmentation is not supported. Fragmentation, and the 265 related mechanisms of MTU discovery, are a significant operational 266 problem in the current Internet [I-D.ietf-intarea-frag-fragile]. We 267 simply abolish this problem area in SOIP. It is designed for use in 268 managed networks where a single size of maximum transmission unit 269 (MTU) is available everywhere. An SOIP network will have a globally 270 defined MTU. Of course, IPv4 and IPv6 reachability services via the 271 open Internet will have to support PMTUD and fragmentation as best 272 they can, but this concerns the embedded IP packets, not the SOIP 273 packets, and will be invisible locally. 275 Appendix A outlines possible TLV and CBOR encodings of the SOIP 276 protocol. 278 3. Coexistence Issues 280 SOIP is expected to coexist with IPv6; in a sense it is a low-level 281 method of orchestrating IPv6 connections. We assume that each SOIP 282 client host has at least one IPv6 address, and that SOIP routers will 283 announce themselves using a suitable IPv6 Router Advertisement 284 extension [I-D.troan-6man-universal-ra-option]. Normally, the first- 285 hop SOIP router will be the same as the IPv6 first-hop router. 287 As a result of this, all standard management mechanisms such as 288 NETCONF may be used without further specification. Also, when a data 289 connection of any kind is established after a SOIP request/response 290 exchange, all standard transport mechanisms are available over IPv6. 291 As noted above, they are subject to the locally defined MTU as long 292 as they remain within the SOIP domain. 294 We do not define how SOIP would operate in an IPv4-only network. 296 4. Some Usage Examples 298 o Storage request (upload content): 300 * Service data identifies storage requirement (temporary/ 301 permanent, private/public, encryption, etc.) 303 * Payload identifies data (path/name.format, etc.) 305 o Storage request (download content): 307 * Service data identifies transmission requirement (streamed, 308 block, etc. and the specific transport protocol - UDP, TCP, 309 QUIC, etc. - if needed) 311 * Payload identifies data (path/name.format, etc.) 313 o Computation request 315 * Service data identifies computing requirement 317 * Payload identifies computing application 319 o Reachability request 321 * Service data gives destination IP address (or DNS name) 323 * Indication of transport protocol required (details TBD) 325 * Indication of options or extension headers required (details 326 TBD) 328 5. Continuity with the Existing Internet 330 Continuity is provided in two ways: 332 1. A user node can simply use IP completely in parallel with SOIP. 333 The network stack in the user node will simply encode the IP 334 packets as SOIP packets with the SAT for IP reachability, and a 335 gateway function will send and receive IP packets at the SOIP 336 domain boundary. 338 2. If a service in the SOIP domain needs service from elsewhere in 339 the IP Internet to respond to a user request, it will use a 340 gateway function to do so.This could also be described as a proxy 341 mechanism. (Of course, services in interconnected SOIP domains 342 may talk to each other directly.) 344 6. Security Considerations 346 It is intended that both authentication and encryption should be 347 available for all SOIP packets. However, this requires further work, 348 especially to determine whether existing mechanisms for key 349 management can be used. 351 Since clients are identified by an IPv6 address, existing layer 3 352 privacy considerations for IPv6 addresses will apply to SOIP. 353 (References needed.) Upper layer privacy considerations will depend 354 on the service concerned. 356 7. IANA Considerations 358 This document makes no request of the IANA. 360 8. References 362 [I-D.carpenter-limited-domains] 363 Carpenter, B. and B. Liu, "Limited Domains and Internet 364 Protocols", draft-carpenter-limited-domains-07 (work in 365 progress), April 2019. 367 [I-D.ietf-cbor-cddl] 368 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 369 definition language (CDDL): a notational convention to 370 express CBOR and JSON data structures", draft-ietf-cbor- 371 cddl-08 (work in progress), March 2019. 373 [I-D.ietf-intarea-frag-fragile] 374 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 375 and F. Gont, "IP Fragmentation Considered Fragile", draft- 376 ietf-intarea-frag-fragile-09 (work in progress), February 377 2019. 379 [I-D.troan-6man-universal-ra-option] 380 Troan, O., "The Universal IPv6 Router Advertisement Option 381 (experiment)", draft-troan-6man-universal-ra-option-01 382 (work in progress), December 2018. 384 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 385 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 386 October 2013, . 388 [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, 389 "Requirements for IPv6 Customer Edge Routers to Support 390 IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May 391 2019, . 393 Appendix A. Possible TLV and CBOR Encodings 395 A.1. TLV Mapping 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 |Version|R R R R| SAT |M F F F A E R R| Traffic Class | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Session Identifier (32 bits) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Hop Limit | | 403 +-+-+-+-+-+-+-+-+ + 404 | | 405 + + 406 | Client Locator / Identifier (128 bits) | 407 + + 408 | | 409 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | SD length | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 412 | | 413 + Service Data (variable length) + 414 ... ... 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Payload Length | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + 418 | | 419 + Payload Data (variable length) + 420 ... ... 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 2 425 Version - IP version number TBD 427 R - Reserved, must be zero 429 SAT - Service Action Type code 431 M - Mobile flag 432 FFF - Flow type flags (FFF = 000 for single-packet flows; other 433 values for longer flows) 435 A - Authentication flag 437 E - Privacy (encryption) flag 439 Traffic class, exactly as for IPv6 441 Session identifier, 32-bit pseudo random number 443 Client Locator / Identifier - globally unique IPv6 address 445 A.2. CBOR Mapping 447 The packet consists of a CBOR byte string preceded by a single byte 448 whose format is: 450 +-+-+-+-+-+-+-+-+ 451 |Version|R R R R| 452 +-+-+-+-+-+-+-+-+ 454 Figure 3 456 For example, for version 7, this byte would be 0x70. This byte is 457 not decoded as CBOR. The CBOR bytes then obey the following CDDL 458 [I-D.ietf-cbor-cddl] specification: 460 sat-packet = [sat, flags, traffic-class, session-id, hop-limit, 461 source, service-data, ?payload] 463 sat = 0..255 464 flags = bytes .size 1 465 traffic-class = 0..255 466 session-id = 0..4294967295 ;up to 32 bits 467 hop-limit = 0..255 468 client = ipv6-address 469 service-data = any 470 payload = any 472 ipv6-address = bytes .size 16 474 Figure 4 476 The syntax of the various service-data formats can be defined in 477 separate documents for each SAT value. 479 We assume that routers capable of handling a CBOR-based layer 3 480 protocol will exist, and will use some form of programmable network 481 processor rather than traditional ASIC or FPGA designs. This allows 482 great flexibility and software-friendly extensibility, especially of 483 the service data formats. Further investigation is needed whether 484 this is realistic. 486 Appendix B. Change log [RFC Editor: Please remove] 488 draft-jiang-service-oriented-ip-00, 2019-05-07: 490 Initial version 492 Authors' Addresses 494 Brian Carpenter 495 The University of Auckland 496 School of Computer Science 497 University of Auckland 498 PB 92019 499 Auckland 1142 500 New Zealand 502 Email: brian.e.carpenter@gmail.com 504 Sheng Jiang 505 Huawei Technologies Co., Ltd 506 Q14, Huawei Campus, No.156 Beiqing Road 507 Hai-Dian District, Beijing, 100095 508 P.R. China 510 Email: jiangsheng@huawei.com 512 Guangpeng Li 513 Huawei Technologies 514 Q14, Huawei Campus 515 No.156 Beiqing Road 516 Hai-Dian District, Beijing 100095 517 P.R. China 519 Email: liguangpeng@huawei.com