< draft-jiang-service-oriented-ip-00.txt   draft-jiang-service-oriented-ip-01.txt >
Network Working Group B. Carpenter Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Intended status: Informational S. Jiang Intended status: Informational S. Jiang
Expires: November 8, 2019 Huawei Technologies Co., Ltd Expires: December 23, 2019 Huawei Technologies Co., Ltd
G. Li G. Li
Huawei Technologies Huawei Technologies
May 7, 2019 June 21, 2019
Service Oriented Internet Protocol Service Oriented Internet Protocol
draft-jiang-service-oriented-ip-00 draft-jiang-service-oriented-ip-01
Abstract Abstract
This document proposes a new, backwards-compatible, approach to This document proposes a new, backwards-compatible, approach to
packet forwarding, where the service required rather than the IP packet forwarding, where the service required rather than the IP
address required acts as the vector for routing packets at the edge address required acts as the vector for routing packets at the edge
of the network. of the network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2019. This Internet-Draft will expire on December 23, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
3. Coexistence Issues . . . . . . . . . . . . . . . . . . . . . 6 3. Coexistence Issues . . . . . . . . . . . . . . . . . . . . . 6
4. Some Usage Examples . . . . . . . . . . . . . . . . . . . . . 7 4. Some Usage Examples . . . . . . . . . . . . . . . . . . . . . 7
5. Continuity with the Existing Internet . . . . . . . . . . . . 7 5. Continuity with the Existing Internet . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Possible TLV and CBOR Encodings . . . . . . . . . . 9 Appendix A. Possible TLV and CBOR Encodings . . . . . . . . . . 9
A.1. TLV Mapping . . . . . . . . . . . . . . . . . . . . . . . 9 A.1. TLV Mapping . . . . . . . . . . . . . . . . . . . . . . . 9
A.2. CBOR Mapping . . . . . . . . . . . . . . . . . . . . . . 10 A.2. CBOR Mapping . . . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Change log [RFC Editor: Please remove] . . . . . . . 11 Appendix B. Change log [RFC Editor: Please remove] . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
An important aspect of the Internet today is that it is no longer a An important aspect of the Internet today is that it is no longer a
uniform space with uniform requirements. For both technical and uniform space with uniform requirements. For both technical and
economic reasons, we see an emerging trend of usage scenarios that economic reasons, we see an emerging trend of usage scenarios that
are confined to some form of limited domain, and which inevitably are confined to some form of limited domain, and which inevitably
lead to applications and protocols that are only suitable within a lead to applications and protocols that are only suitable within a
given scope [I-D.carpenter-limited-domains]. This trend collides given scope [I-D.carpenter-limited-domains]. This trend collides
immediately with two factors: the original design concept of an immediately with two factors: the original design concept of an
skipping to change at page 3, line 9 skipping to change at page 3, line 9
cost way. As a result, transport protocols such as TCP and UDP learn cost way. As a result, transport protocols such as TCP and UDP learn
little or nothing about the network, beyond congestion or loss little or nothing about the network, beyond congestion or loss
signals. Several ISPs may lie on the path between a user and a signals. Several ISPs may lie on the path between a user and a
server, but they are largely ignorant about the services a user server, but they are largely ignorant about the services a user
requires. Typical services could be streamed content, regular requires. Typical services could be streamed content, regular
content, user posting, storage access, or calculation, but this list content, user posting, storage access, or calculation, but this list
is not exclusive. is not exclusive.
Both service providers and users will benefit if a packet stream can Both service providers and users will benefit if a packet stream can
be identified intrinsically as requiring a certain kind of service. be identified intrinsically as requiring a certain kind of service.
Whatever the business model - for example the ISP operates all types This is particularly applicable for edge networks, such as those
of service, or the ISP operates no user services at all and has supported by 5G technology, where there is an emphasis on upper layer
contracts with specific service providers, or the ISP is agnostic service provision. Whatever the business model - for example the ISP
about user services - SOIP will allow for optimised packet delivery. operates all types of service, or the ISP operates no user services
The ISP will have the choice to provide some or all services. The at all and has contracts with specific service providers, or the ISP
user will have the choice to use ISP services or bypass them. is agnostic about user services - SOIP will allow for optimised
Traffic that leaves the domain where SOIP is in use will be perfectly packet delivery. The ISP will have the choice to provide some or all
normal IPv6 or IPv4 traffic, sent by an exit node acting as a proxy services. The user will have the choice to use ISP services or
(not an IP-layer translator) for the user. Additionally, IPv6 and bypass them. Traffic that leaves the domain where SOIP is in use
IPv4 will be modelled as services available to the user, thereby will be perfectly normal IPv6 or IPv4 traffic, sent by an exit node
giving continuity of access to everything the user has today. This acting as a proxy (not an IP-layer translator) for the user.
is a logical extension of a principle already adopted to model IPv4 Additionally, IPv6 and IPv4 will be modelled as services available to
as a service available via IPv6 [RFC8585]. the user, thereby giving continuity of access to everything the user
has today. This is a logical extension of a principle already
adopted to model IPv4 as a service available via IPv6 [RFC8585].
2. Proposed Solution 2. Proposed Solution
NOTE: This is a preliminary draft expected to stimulate discussion, NOTE: This is a preliminary draft expected to stimulate discussion,
so many details are not yet defined. so many details are not yet defined.
The approach is to make the service be the central component of the The approach is to make the service be the central component of the
network. Conceptually, the user's packets will be directed at a network. Conceptually, the user's packets will be directed at a
service, not at an IP host. service, not at an IP host.
skipping to change at page 8, line 31 skipping to change at page 8, line 41
on the service concerned. on the service concerned.
7. IANA Considerations 7. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
8. References 8. References
[I-D.carpenter-limited-domains] [I-D.carpenter-limited-domains]
Carpenter, B. and B. Liu, "Limited Domains and Internet Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", draft-carpenter-limited-domains-07 (work in Protocols", draft-carpenter-limited-domains-08 (work in
progress), April 2019. progress), June 2019.
[I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to
express CBOR and JSON data structures", draft-ietf-cbor-
cddl-08 (work in progress), March 2019.
[I-D.ietf-intarea-frag-fragile] [I-D.ietf-intarea-frag-fragile]
Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", draft- and F. Gont, "IP Fragmentation Considered Fragile", draft-
ietf-intarea-frag-fragile-09 (work in progress), February ietf-intarea-frag-fragile-12 (work in progress), June
2019. 2019.
[I-D.troan-6man-universal-ra-option] [I-D.troan-6man-universal-ra-option]
Troan, O., "The Universal IPv6 Router Advertisement Option Troan, O., "The Universal IPv6 Router Advertisement Option
(experiment)", draft-troan-6man-universal-ra-option-01 (experiment)", draft-troan-6man-universal-ra-option-01
(work in progress), December 2018. (work in progress), December 2018.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support "Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/info/rfc8585>. 2019, <https://www.rfc-editor.org/info/rfc8585>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
Appendix A. Possible TLV and CBOR Encodings Appendix A. Possible TLV and CBOR Encodings
A.1. TLV Mapping A.1. TLV Mapping
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|R R R R| SAT |M F F F A E R R| Traffic Class | |Version|R R R R| SAT |M F F F A E R R| Traffic Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (32 bits) | | Session Identifier (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Limit | | | Hop Limit | |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| Client Locator / Identifier (128 bits) | | Client Locator / Identifier (128 bits) |
skipping to change at page 10, line 30 skipping to change at page 11, line 18
whose format is: whose format is:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Version|R R R R| |Version|R R R R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Figure 3
For example, for version 7, this byte would be 0x70. This byte is For example, for version 7, this byte would be 0x70. This byte is
not decoded as CBOR. The CBOR bytes then obey the following CDDL not decoded as CBOR. The CBOR bytes then obey the following CDDL
[I-D.ietf-cbor-cddl] specification: [RFC8610] specification:
sat-packet = [sat, flags, traffic-class, session-id, hop-limit, sat-packet = [sat, flags, traffic-class, session-id, hop-limit,
source, service-data, ?payload] source, service-data, ?payload]
sat = 0..255 sat = 0..255
flags = bytes .size 1 flags = bytes .size 1
traffic-class = 0..255 traffic-class = 0..255
session-id = 0..4294967295 ;up to 32 bits session-id = 0..4294967295 ;up to 32 bits
hop-limit = 0..255 hop-limit = 0..255
client = ipv6-address client = ipv6-address
skipping to change at page 11, line 18 skipping to change at page 11, line 52
great flexibility and software-friendly extensibility, especially of great flexibility and software-friendly extensibility, especially of
the service data formats. Further investigation is needed whether the service data formats. Further investigation is needed whether
this is realistic. this is realistic.
Appendix B. Change log [RFC Editor: Please remove] Appendix B. Change log [RFC Editor: Please remove]
draft-jiang-service-oriented-ip-00, 2019-05-07: draft-jiang-service-oriented-ip-00, 2019-05-07:
Initial version Initial version
draft-jiang-service-oriented-ip-01, 2019-06-21:
Editorial corrections
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
The University of Auckland The University of Auckland
School of Computer Science School of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
 End of changes. 14 change blocks. 
31 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/