intarea Z. Zhang
Internet-Draft R. Bonica
Intended status: Standards Track K. Kompella
Expires: October 23, 2021 Juniper Networks
G. Mirsky
ZTE
April 21, 2021
Generic Delivery Functions
draft-zzhang-intarea-generic-delivery-functions-01
Abstract
Some functionalities (e.g., fragmentation/reassembly and
Encapsulating Security Payload) provided by IPv6 can be viewed as
delivery functions independent of IPv6 or even IP entirely. This
document proposes to provide those functionalities at different
layers (e.g., MPLS, BIER or even Ethernet) independent of IP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 23, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Zhang, et al. Expires October 23, 2021 [Page 1]
Internet-Draft Generic Delivery Functions April 2021
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Generic Delivery Function Header . . . . . . . . . . . . 4
2.2. Generic Fragmentation Header . . . . . . . . . . . . . . 5
2.3. Payload Type Header . . . . . . . . . . . . . . . . . . . 6
2.4. Generic ESP/Authentication Header . . . . . . . . . . . . 6
2.5. GDFH in an MPLS Data Plane . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Consider an operator providing Ethernet services such as EVPN. The
Ethernet frames that a Provider Edge (PE) device receives from a
Customer Edge (CE) device may have a larger size than the PE-PE path
MTU (PMTU) in the provider network. This could be because
1. the provider network is built upon virtual connections (e.g.,
pseudowires) provided by another infrastructure provider, or
2. the customer network uses jumbo frames while the provider network
does not, or
3. the provider-side overhead for transporting customer packets
across the network pushes past the PMTU.
In any case, the provider cannot simply require its customers to
change their MTU.
To get those large frames across the provider network, currently, the
only workaround is to encapsulate the frames in IP (with or without
GRE) and then fragment the IP packets. Even if MPLS is used for
service delimiting, IP is used for transportation (MPLS over IP/GRE).
This may not be desirable in certain deployment scenarios, where MPLS
is the preferred transport or IP encapsulation overhead is deemed
excessive.
Zhang, et al. Expires October 23, 2021 [Page 2]
Internet-Draft Generic Delivery Functions April 2021
IPv6 fragmentation and reassembly are based on the IPv6 Fragmentation
header below [RFC8200]:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Fragmentation Header
This document proposes adapting this header for use in non-IP
contexts since the fragmentation/reassembly function is actually
independent of IPv6 except for the following aspects:
o The fragment header is identified as such by the "previous"
header.
o The "Next Header" value is from the "Internet Protocol Numbers"
registry.
o The "Identification" value is unique in the (source, destination)
context provided by the IPv6 header.
The "Identification" field, in conjunction with the IPv6 source and
destination addresses identifies fragments of the original packet for
the purpose of reassembly.
Therefore, the fragmentation/reassembly function can be applied at
other layers as long as a) the fragment header is identified as such;
and b) the context for packet identification is provided. Examples
of such layers include MPLS, BIER, and Ethernet (if IEEE determines
it is so desired).
For the same consideration, the IP Encapsulating Security Payload
(ESP) [RFC4303] could also be applied at other layers if ESP is
desired there. For example, if for whatever reason the Ethernet
service provider wants to provide ESP between its PEs, it could do so
without requiring IP encapsulation if ESP is applied at non-IP
layers.
We refer to these as Generic Delivery Functions (GDFs), which could
be achieved at a shim layer between a source and destination delivery
points, for example:
o Source and destination IP/Ethernet nodes
o Ingress and egress nodes of MPLS Label Switch Paths (LSPs)
Zhang, et al. Expires October 23, 2021 [Page 3]
Internet-Draft Generic Delivery Functions April 2021
o BIER Forwarding Ingress Routers (BFIRs) and BIER Forwarding Egress
Routers (BFERs)
It is not the intended to apply the GDFs hop by hop between the
source and destination delivery points.
The possibility of applying some other IP functions (e.g.,
Authentication Header [RFC4302]) is for further study.
2. Specifications
2.1. Generic Delivery Function Header
The following Generic Delivery Function Header (GDFH) is defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Rsved | Header Length | Next Header | This Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Variable field per "This header" ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generic Delivery Function Header
0000 nibble: Prevents the GDFH from being mistaken for an IP header
by a router doing deep packet inspection for ECMP hashing
purposes.
Header Length: The length of header in the number of 4-octet units.
Next Header: The type of next header. For functions that IETF is
concerned with, the "Next Header" values are from the "Internet
Protocol Numbers" registry (e.g., the next header could be a TCP
or UDP or MPLS header). The next header could be another GDFH,
and a value for GDFH will be assigned by IANA from that registry.
This Header: The type of this GDFH header. For example, TBD1 for
generic fragmentation, TBD2 for generic ESP. The values are from
a space independent of the "Next Header".
The outer header MUST identify that a GDFH follows. Encoding "This
Header" in the GDFH allows a single outer header encoding to be used
for different GDFHs.
If the outer header is BIER, a TBD value for the "proto" field in the
BIER header identifies that a GDFH follows.
If the outer header is MPLS, the label preceding the GDFH indicates
that a GDFH follows (see Section 2.5).
Zhang, et al. Expires October 23, 2021 [Page 4]
Internet-Draft Generic Delivery Functions April 2021
If the outer header is Ethernet (if IEEE would decide to provide the
generic delivery functions on top of Ethernet directly), then a new
Ethertype would be assigned by IEEE.
2.2. Generic Fragmentation Header
For generic fragmentation/reassembly functionality, the GDFH takes
the following Generic Fragmentation Header (GFH) format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Rsved | Header Length | Next Header | TBD1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset |R|S|M| Identification (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| (continues)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Generic Fragmentation Header
The "Fragment Offset" and "M" flag bit fields are as defined for the
IPv6 Fragmentation Header in Section 4.5 [RFC8200].
R: The "R" flag bit is reserved. It MUST be set to 0 on transmit and
ignored on receive.
Identification: at least 4-octet long. // would 2-octet be ok as a
minimum?
S: If the "S" flag bit is clear, the context for the Identification
field is provided by the outer header, and only the source-
identifying information in the outer header is used.
If the "S" flag bit is set, the variable Identification field
encodes both source-identifying information (e.g., the IP address
of the node adding the GFH) and an identification number unique
within that source.
When a GFH is used together with other GDFHs, the GFH SHOULD be the
first GDFH.
If the outer header is BIER and the "S" flag bit is clear, the "BFIR-
id" field in the BIER header provides the context for the
"Identification" field.
If the outer header is MPLS, the "S" flag bit MAY be clear if the
label preceding the GFH identifies the sending node in addition to
indicating that a GFH follows (see Section 2.5).
Zhang, et al. Expires October 23, 2021 [Page 5]
Internet-Draft Generic Delivery Functions April 2021
2.3. Payload Type Header
While originally it is not the intention to provide a way to identify
the payload type after an MPLS label stack, it has been pointed out
that the GFH now provides the payload-identifying functionality as a
by-product - even when fragmentation is not needed, a GFH can be
inserted, with the Fragmentation Offset, the M-bit and Identification
fields set to 0, and the Next Header set appropriately.
If the payload-identifying functionality is deemed as desired, a
dedicated header type could be assigned for this purpose, with a
smaller header compared to GFH.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Rsved |Header Length:1| Next Header | TBD3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Generic Payload Type Header
2.4. Generic ESP/Authentication Header
To be specified in future revisions.
2.5. GDFH in an MPLS Data Plane
When GDFH is used in a network with MPLS data plane, the BoS label
indicates that a GDFH immediately follows. The label can be either a
special purpose label or a regular label signaled via BGP or IGP.
The details will be provided in future revisions.
3. Security Considerations
To be provided.
4. Acknowledgements
The authors thank Stewart Bryant and Tony Przygienda for their
valuable comments and suggestions.
5. References
5.1. Normative References
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
Zhang, et al. Expires October 23, 2021 [Page 6]
Internet-Draft Generic Delivery Functions April 2021
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
5.2. Informative References
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Zhang, et al. Expires October 23, 2021 [Page 7]
Internet-Draft Generic Delivery Functions April 2021
Ron Bonica
Juniper Networks
Email: rbonica@juniper.net
Kireeti Kompella
Juniper Networks
Email: kireeti@juniper.net
Gregory Mirsky
ZTE
Email: gregory.mirsky@ztetx.com
Zhang, et al. Expires October 23, 2021 [Page 8]