Dissemination of BGP Flow Specification Rules for APN
draft-peng-apn-bgp-flowspec-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Shuping Peng , Zhenbin Li , Sheng Fang , Yong Cui | ||
| Last updated | 2022-04-28 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-peng-apn-bgp-flowspec-01
Network Working Group S. Peng
Internet-Draft Z. Li
Intended status: Standards Track S. Fang
Expires: 31 October 2022 Huawei Technologies
Y. Cui
Tsinghua University
29 April 2022
Dissemination of BGP Flow Specification Rules for APN
draft-peng-apn-bgp-flowspec-01
Abstract
A BGP Flow Specification is an n-tuple consisting of several matching
criteria that can be applied to IP traffic. Application-aware
Networking (APN) is a framework, where APN data packets convey APN
attribute including APN ID and/or APN Parameters. The dynamic Flow
Spec mechanism for APN is designed for the new applications of
traffic filtering in an APN domain as well as the traffic control and
actions at the policy enforcement points in this domain. These
applications require coordination among the ASes within a service
provider.
This document specifies a new BGP Flow Spec Component Type in order
to support APN traffic filtering. The match field is the APN ID. It
also specifies traffic filtering actions to enable the creation of
the APN ID in the outer tunnel encapsulation when matched to the
corresponding Flow Spec rules.
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 31 October 2022.
Peng, et al. Expires 31 October 2022 [Page 1]
Internet-Draft APN FlowSpec Dissemination April 2022
Copyright Notice
Copyright (c) 2022 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 include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Flow Specifications for APN . . . . . . . . . . . . . . . . . 4
5. Component Type for APN . . . . . . . . . . . . . . . . . . . 5
5.1. APN ID - Type TBD1 . . . . . . . . . . . . . . . . . . . 5
5.2. Encoding Example . . . . . . . . . . . . . . . . . . . . 5
6. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Ordering of Flow Specifications . . . . . . . . . . . . . 6
6.2. Encoding format of the Grouping Identifier Extend Community
Sub-Type TBD2 . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Usage Principles . . . . . . . . . . . . . . . . . . . . 7
6.4. Usage example . . . . . . . . . . . . . . . . . . . . . . 8
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 10
7.1. Traffic Marking (traffic-marking-apn) Sub-Type TBD3 . . . 11
7.2. Traffic Marking (traffic-marking-apn-partial) Sub-Type
TBD4 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Inherit (inherit-apn) Sub-Type TBD5 . . . . . . . . . . . 13
7.4. Stitch (stitch-apn) Sub-Type TBD6 . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Flow Spec Component - APN ID . . . . . . . . . . . . . . 14
8.2. Opaque Extended Community - Grouping Identifier . . . . . 15
8.3. Extended Community Flow Specification Actions . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Peng, et al. Expires 31 October 2022 [Page 2]
Internet-Draft APN FlowSpec Dissemination April 2022
1. Introduction
A Flow Specification (Flow Spec) is an n-tuple consisting of several
matching criteria that can be applied to IP traffic [RFC8955]. The
Flow Spec conveys match conditions (each may include several
components) which are encoded using MP_REACH_NLRI and MP_UNREACH_NLRI
attributes [RFC4760], while the associated actions such as redirect
and traffic marking are encoded in BGP Extended Communities
[RFC4360][RFC5701]. The IPv4 NLRI component types and traffic
filtering actions sub-types are described in [RFC8955], while the
IPv6 related are described in [RFC8956].
[I-D.ietf-idr-flowspec-l2vpn] extends the flow-spec rules and actions
for Ethernet Layer 2 and L2VPN. The corresponding (AFI, SAFI) pairs
are defined by IANA, respectively. [I-D.hares-idr-flowspec-v2]
specifies BGP Flow Specification Version 2.
Application-aware Networking (APN) is introduced in
[I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases].
APN data packets convey the APN attribute (incl. APN ID and/or APN
Parameters). The APN ID is a structured value, treated as an opaque
object in the network, to which the network operator applies policies
in various nodes/service functions along the path so to provide
corresponding services. For an IPv6 network, a design proposal of
such structured value is provided by
[I-D.li-apn-header][I-D.li-apn-ipv6-encap]. The APN attribute can be
encapsulated in various data planes adopted within a Network Operator
controlled limited domain, e.g. IPv6, MPLS, and other tunnel
technologies, which wait to be further specified.
With APN, it becomes possible to apply various policies in different
nodes along a network path onto a traffic flow overall in a more
efficient way, that is, at the headend to steer into corresponding
path, at the midpoint to collect corresponding performance
measurement data, and at the service function to execute particular
policies. Prior to APN, there was no efficient way to realize this
composite network service provisioning along the path.
This document specifies a new BGP Flow Spec Component Type to support
APN traffic filtering. The match field is the APN APN ID
[I-D.li-apn-framework]. It also specifies traffic filtering actions
to enable the creation of the APN ID in the outer tunnel
encapsulation when matched to the corresponding Flow Spec rules.
Depends upon specific deployment requirements, the functions
specified in this draft can also be applied on BGP Flow Specification
Version 2, which will be specified in the future versions.
Peng, et al. Expires 31 October 2022 [Page 3]
Internet-Draft APN FlowSpec Dissemination April 2022
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
appear in all capitals, as shown here.
3. Terminologies
APN: Application-aware Networking
APN ID: APN Identifier
AS: Autonomous System
Flow Spec: Flow Specification
BGP-FS: Border Gateway Protocol (BGP) Flow Specification (FS)
4. Flow Specifications for APN
The APN framework is introduced in [I-D.li-apn-framework]. The Flow
Spec for APN is shown in Figure 1, that is, the Controller is used to
set up BGP connection with the policy enforcement points in an APN
domain.
+---------------+
/-----| Controller |-----\
/ +---------------+ \
+-----+ FS / | \ FS +-----+
|App x|-\ / FS FS FS \ /-|App x|
+-----+ | +--/-+ +----/-------|-------\----+ +-\--+ | +-----+
\-|APN | | APN Network | |APN |-/
|- |--|Policy Enforcement Points|--|- |
/-|Edge| | incl. multi-domains | |Edge|-\
+-----+ | +----+ +-------------------------+ +----+ | +-----+
|App y|-/ | | \-|App y|
+-----+ |<--- Network Operator Controlled --->| +-----+
Limited Domain
Figure 1. Flow Spec for APN
Peng, et al. Expires 31 October 2022 [Page 4]
Internet-Draft APN FlowSpec Dissemination April 2022
5. Component Type for APN
The IPv4 NLRI component types are defined in [RFC8955], while the
IPv6 related are specified in [RFC8956]. This document defines a new
component type for APN.
5.1. APN ID - Type TBD1
Encoding: <type (1 octet), length (1 octet), mask (variable), APN ID
(variable)>
Defines the APN ID to match. The mask is used to indicate the bits
of the APN ID carried in the packet which are used to match against
the APN ID value in this Flow Spec component.
type (1 octet): This indicates the new component type TBD1.
length (1 octet): This indicates the length of the mask and the
length of the APN ID. The mask and the APN ID have the same length.
mask (variable): This indicates the bits of the APN ID carried in the
data packet which are used to match.
APN ID (variable): This indicates the APN ID that is used for the
match.
5.2. Encoding Example
Since the APN ID is a structured value, the mask in the Flow Spec is
used to enable flexible matching of the particular parts of the APN
ID.
As an example, shown in Figure 2, the APN ID in the data packet
contains two parts, the APP Group ID (0x300A) and User Group ID
(0x0C08). In the Flow Spec, the mask is 0xFFFF0000 and the APN ID is
0x300A0000. Processing the match of the APN ID component is done by
using the mask (0xFFFF0000) to indicate the bits of the APN ID
carried in the packet to be matched against the one carried in the
Flow Spec (0x300A0000). The result of this example is a successful
match.
Peng, et al. Expires 31 October 2022 [Page 5]
Internet-Draft APN FlowSpec Dissemination April 2022
in packet
+---+---+---+---+---+---+---+---+
APN | APP GROUP ID | User Group ID |\
ID +---+---+---+---+---+---+---+---+ \
|____
in FlowSpec | |
+---+---+---+---+---+---+---+---+ / /
mask | 1 | 1 | 1...1 | 0 | 0 | 0...0 |/ /
+---+---+---+---+---+---+---+---+ /
& /
+---+---+---+---+---+---+---+---+ /
APN | APP GROUP ID | 0 | 0 | 0...0 |/_
ID +---+---+---+---+---+---+---+---+
Figure 2. The match example of the APN ID component
6. Traffic Filtering
Traffic filtering policies have been traditionally considered to be
relatively static. The dynamic Flow Spec mechanism for APN is
designed for the new applications of traffic filtering in an APN
domain as well as the traffic control and actions on the policy
enforcement points in this domain. These applications require
coordination among the ASes within a service provider. The new
component and encoding are defined in Section 4. The actions are
defined in this section.
6.1. Ordering of Flow Specifications
More than one Flow Specification rule may match a particular traffic
flow at a node. The co-existing rules are mixed and need to be
effectively organized. However, there is still no efficient way to
achieve such classification. Thus, it is necessary to specify the
grouping mechanism for the Flow Specification rules to be matched in
a desired order as well as the actions being applied to a particular
traffic flow. This ordering function is such that it does not depend
on the arrival order of the Flow Specification via BGP and thus is
consistent in the network [RFC8955].
The definition of this ordering is very important to the Flow Spec
for APN because of the following reasons.
1. There can be other co-existing Flow Spec rules (e.g. based on
5-tuple) rather than only APN Flow Spec rules (i.e. based on APN ID).
2. The different parts of the APN ID can be determined by the
different Flow Spec rules.
Peng, et al. Expires 31 October 2022 [Page 6]
Internet-Draft APN FlowSpec Dissemination April 2022
Therefore, the ordering of the Flow Spec rules for APN needs to be
clearly specified.
6.2. Encoding format of the Grouping Identifier Extend Community Sub-
Type TBD2
We define a Grouping Identifier Opaque Extend Community [RFC4360]
(Sub-Type = TBD2) carrying both Group ID (2 octets) and Sub-group ID
(2 octets) and indicating the grouping of the Flow Spec rules it
accompanies.
The encoding format of the Grouping Identifier Opaque Extend
Community is as follows.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 or 0x43 |Sub-Type = TBD2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Encoding of the Grouping Identifier Extend Community
6.3. Usage Principles
The following principles are defined.
1. Within a sub-group, the order is the same as the previously
defined.
* If the traffic-action Extended Community is carried and the
Terminal Action (T, bit 47) [RFC8955] is not set, when one
condition in this sub-group is matched, the evaluation of any
subsequent flow specifications within this sub-group stops; if T
is set, then the evaluation continues;
* If the traffic-action Extended Community is not carried, when one
condition in this sub-group is matched, the evaluation of any
subsequent flow specifications within this sub-group stops;
Peng, et al. Expires 31 October 2022 [Page 7]
Internet-Draft APN FlowSpec Dissemination April 2022
2. Between sub-groups, the sub-group is ordered by increasing Sub-
group ID, when the evaluation in one sub-group stops or finishes, it
will start the evaluation in the following sub-group if there are any
sub-groups.
3. Between groups, the group is ordered by increasing Group ID, if
at least one condition in this group is matched, when the evaluation
of the flow specifications within the group reaches the end, the
evaluation stops so the evaluation of the following group(s) will not
start.
6.4. Usage example
At the APN Edge where the APN ID is created based on the Flow
Specifications and encapsulated in the outer tunnel header
[I-D.li-apn-framework], more than one Flow Specification rule
condition may match a particular traffic flow. The different parts
of the APN ID can be determined by the different Flow Spec rules.
For example, as shown in Figure 4, the App Group ID is created by
matching the 5-tuple components (e.g. destination IP address and
transport layer ports), the User Group ID is created by matching the
access ports, and the Reserved (R.) Group ID is created by matching
the 5-tuple components.
Moreover, there are also other co-existing Flow Spec rules mixed at
the node rather than only APN Flow Spec rules (i.e. based on APN ID).
All the rules need to be effectively organized and applied to the
particular traffic flow in a desired order.
In Figure 4, the Flow Specification rules for APN and other existing
rules are categorized into two groups, and given Group ID = 1 and 2,
respectively. The Flow Specification rules for creating different
parts of the APN ID are categorized into three sub-groups, and given
Sub-Group ID = 1, 2, and 3, respectively.
Based on the usage principles described in the above section, for the
case of APN as shown in Figure 4, the usage principles are as
follows,
1. Within a sub-group, the order is the same as the previously
defined.
Peng, et al. Expires 31 October 2022 [Page 8]
Internet-Draft APN FlowSpec Dissemination April 2022
* If the traffic-action Extended Community is carried and the
Terminal Action (T, bit 47) [RFC8955] is not set, when one
condition in this sub-group is matched, the evaluation of any
subsequent flow specifications within this sub-group stops and the
App Group ID is created; if T is set, then the evaluation
continues and the App Group ID will be created if there is a match
within this sub-group;
* If the traffic-action Extended Community is not carried, when one
condition in this sub-group is matched, the evaluation of any
subsequent flow specifications within this sub-group stops and the
App Group ID is created;
2. Between sub-groups, the sub-group is ordered with Sub-group ID,
when the evaluation in the Sub-group ID = 1 stops or finishes, it
will start the evaluation in the following Sub-group ID = 2 and
create the User Group ID if matched, and then the Sub-group ID = 3 to
create the R. Group ID if matched.
3. Between groups, the group is ordered with Group ID, if at least
one condition in this Group ID = 1 is matched, when the evaluation of
the flow specifications within the group reaches the end, the
evaluation stops and the APN ID is created. The evaluation of the
following group(s) will not start, that is, the Group ID = 0 will not
be evaluated.
Group ID = 1, Sub-Group ID = 1
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | App Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | App Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | App Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----------------------------------------------------------
Group ID = 1, Sub-Group ID = 2
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule ( ports )| | User Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule ( ports )| | User Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule ( ports )| | User Group ID |
Peng, et al. Expires 31 October 2022 [Page 9]
Internet-Draft APN FlowSpec Dissemination April 2022
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----------------------------------------------------------
Group ID = 1, Sub-Group ID = 3
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | R. Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | R. Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | R. Group ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
==========================================================
Group ID = 0, Sub-Group ID = 0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | Actions |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | Actions |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule (5-tuple)| | Actions |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
==========================================================
Figure 4: Usage of Grouping Identifer Extended Community for APN
7. Traffic Filtering Actions
Peng, et al. Expires 31 October 2022 [Page 10]
Internet-Draft APN FlowSpec Dissemination April 2022
+==================+=====================+========================+
| Community 0xttss | action | encoding |
| Sub-Type | | |
+==================+=====================+========================+
| | traffic-marking-apn |4/16-octet APN ID |
| TBD3 | (Section 7.1) |1-octet IPv6 (ExH) Type |
| | |1-octet Reserved |
+------------------+---------------------+------------------------+
| TBD4 | traffic-marking-apn-|4/16-octet Bitmask |
| | partial |4/16-octet APN ID |
| | (Section 7.2) |1-octet IPv6 (ExH) Type |
| | |1-octet Reserved |
+------------------+---------------------+------------------------+
| TBD5 | inherit-apn |4/16-octet Bitmask |
| | (Section 7.3) |1-octet IPv6 (ExH) Type |
| | |1-octet Reserved |
+------------------+---------------------+------------------------+
| TBD6 | stitch-apn |4/16-octet Bitmask |
| | (Section 7.2) |4/16-octet APN ID |
| | |1-octet IPv6 (ExH) Type |
| | |1-octet Reserved |
+------------------+---------------------+------------------------+
7.1. Traffic Marking (traffic-marking-apn) Sub-Type TBD3
The traffic-marking-apn Extended Community instructs a system to
create the APN ID and encapsulate it in the indicated outer tunnel
header of a transiting IP packet.
In this case, the tunnel encapsulation header is IPv6, possibly
followed by an extension header (ExH). The corresponding Extended
Community [RFC5701] is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
| APN ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 (ExH) | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peng, et al. Expires 31 October 2022 [Page 11]
Internet-Draft APN FlowSpec Dissemination April 2022
APN ID: 4/16 octets, APN ID value to be created and encapsulated in
the indicated outer tunnel header of the transiting IP packet.
IPv6 (ExH): 1 octet, the type of each IPv6 extension header
[RFC8200][RFC2780][RFC5871] is directly reused to indicate the outer
tunnel to be used to encapsulate the APN ID.
reserved: 1 octet, MUST be set to 0 on encoding and MUST be ignored
during decoding.
7.2. Traffic Marking (traffic-marking-apn-partial) Sub-Type TBD4
The traffic-marking-apn-partial Extended Community instructs a system
to use the bitmask indicating the bits of the APN ID to be
encapsulated in the indicated outer tunnel header of a transiting IP
packet. The ultimately constructed APN ID may comprise of several
parts obtained by the matches of different rules, and it is
encapsulated in the indicated outer tunnel header.
In this case, the tunnel encapsulation header is IPv6, possibly
followed by an extension header (ExH). The corresponding Extended
Community [RFC5701] is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
| Bitmask |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
| APN ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 (ExH) | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bitmask: 4/16 octets, the same length as the APN ID, indicating the
bits of the APN ID to be encapsulated in the indicated outer tunnel
header.
APN ID: 4/16 octets, the APN ID value to be created and encapsulated
in the indicated outer tunnel header of the transiting IP packet.
Peng, et al. Expires 31 October 2022 [Page 12]
Internet-Draft APN FlowSpec Dissemination April 2022
IPv6 (ExH): 1 octet, the type of each IPv6 extension header
[RFC8200][RFC2780][RFC5871] is directly reused to indicate the outer
tunnel to be used to encapsulate the APN ID.
reserved: 1 octet, MUST be set to 0 on encoding and MUST be ignored
during decoding.
7.3. Inherit (inherit-apn) Sub-Type TBD5
The inherit-apn Extended Community instructs a system to use the
Bitmask to "and" operate on the existing APN ID of a transiting IP
packet and encapsulate the inherited APN ID in the indicated outer
tunnel header.
In this case, the tunnel encapsulation header is IPv6, possibly
followed by an extension header (ExH). The corresponding Extended
Community [RFC5701] is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
| Bitmask |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 (ExH) | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bitmask: 4/16 octets, the same length as the APN ID, to "and" operate
on the existing APN ID of a transiting IP packet.
IPv6 (ExH): 1 octet, the type of each IPv6 extension header
[RFC8200][RFC2780][RFC5871] is directly reused to indicate the outer
tunnel to be used to encapsulate the APN ID.
reserved: 1 octet, MUST be set to 0 on encoding and MUST be ignored
during decoding.
7.4. Stitch (stitch-apn) Sub-Type TBD6
The stitch-apn Extended Community instructs a system to "and" the
Bitmask with the existing APN ID of a transiting IP packet to get the
part to be further encapsulated, and "and" the negation of the
Bitmask with the APN ID in the Flow Spec and get the other part to be
further encapsulated. The stitched APN ID is encapsulated in the
indicated outer tunnel header. That is to say, the Bitmask specifies
Peng, et al. Expires 31 October 2022 [Page 13]
Internet-Draft APN FlowSpec Dissemination April 2022
the bits of the received APN ID to be replaced by the corresponding
bits from the APN ID in the action sub-TLV value to produce a new
outer APN ID. The other bits of the received APN ID are copied to
the new outer AP ID.
In this case, the tunnel encapsulation header is IPv6, possibly
followed by an extension header (ExH). The corresponding Extended
Community [RFC5701] is encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
| Bitmask |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
| APN ID |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 (ExH) | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bitmask: 4/16 octets, the same length as the APN ID, used to operate
on the APN ID (both carried in the transiting IP packet and in the
Flow Spec).
APN ID: 4/16 octets, the APN ID value to be created and encapsulated
in the indicated outer tunnel header of the transiting IP packet.
IPv6 (ExH): 1 octet, the type of each IPv6 extension header
[RFC8200][RFC2780][RFC5871] is directly reused to indicate the outer
tunnel to be used to encapsulate the APN ID.
reserved: 1 octet, MUST be set to 0 on encoding and MUST be ignored
during decoding.
8. IANA Considerations
8.1. Flow Spec Component - APN ID
IANA is requested to assign a value in the Flow Specification
Component Types Registry as follows:
Peng, et al. Expires 31 October 2022 [Page 14]
Internet-Draft APN FlowSpec Dissemination April 2022
+=======+====================+===============+
| Value | Name | Reference |
+=======+====================+===============+
| TBD1 | APN ID | This document |
+-------+--------------------+---------------+
8.2. Opaque Extended Community - Grouping Identifier
The Grouping Identifier Opaque Extended Community is defined in this
document and it is requested that a Sub-Type = TBD2 be assigned as
follows.
+=======+======================+===============+
| Value | Name | Reference |
+=======+======================+===============+
| TBD2 | Grouping Identifier | This document |
+-------+----------------------+---------------+
8.3. Extended Community Flow Specification Actions
The Extended Community Flow Specification Actions are defined in this
document and it is requested that corresponding Sub-Types as shown in
the following table be assigned.
+============+==============================+===============+
| Sub-Type | Name | Reference |
| Value | | |
+============+==============================+===============+
| TBD3 | traffic-marking-apn | This document |
+------------+------------------------------+---------------+
| TBD4 | traffic-marking-apn-partial | This document |
+------------+------------------------------+---------------+
| TBD5 | inherit-apn | This document |
+------------+------------------------------+---------------+
| TBD6 | stitch-apn | This document |
+------------+------------------------------+---------------+
9. Acknowledgements
The authors would like to thank the careful reviews and valuable
comments from Haibo Wang, Shunwan Zhuang, Stefano Previdi, and Donald
Eastlake.
Peng, et al. Expires 31 October 2022 [Page 15]
Internet-Draft APN FlowSpec Dissemination April 2022
10. Security Considerations
The security considerations are the same as [RFC8955], [RFC8956], and
[I-D.li-apn-framework].
11. References
11.1. Normative References
[I-D.hares-idr-flowspec-v2]
Hares, S., Eastlake, D., Yadlapalli, C., and S. Maduschke,
"BGP Flow Specification Version 2", Work in Progress,
Internet-Draft, draft-hares-idr-flowspec-v2-05, 4 February
2022, <https://www.ietf.org/internet-drafts/draft-hares-
idr-flowspec-v2-05.txt>.
[I-D.li-apn-framework]
Li, Z., Peng, S., Voyer, D., Li, C., Liu, P., Cao, C., and
G. Mishra, "Application-aware Networking (APN) Framework",
Work in Progress, Internet-Draft, draft-li-apn-framework-
05, 7 March 2022, <https://www.ietf.org/archive/id/draft-
li-apn-framework-05.txt>.
[I-D.li-apn-header]
Li, Z., Peng, S., and S. Zhang, "Application-aware
Networking (APN) Header", Work in Progress, Internet-
Draft, draft-li-apn-header-02, 7 April 2022,
<https://www.ietf.org/archive/id/draft-li-apn-header-
02.txt>.
[I-D.li-apn-ipv6-encap]
Li, Z., Peng, S., and C. Xie, "Application-aware IPv6
Networking (APN6) Encapsulation", Work in Progress,
Internet-Draft, draft-li-apn-ipv6-encap-04, 7 April 2022,
<https://www.ietf.org/archive/id/draft-li-apn-ipv6-encap-
04.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
Peng, et al. Expires 31 October 2022 [Page 16]
Internet-Draft APN FlowSpec Dissemination April 2022
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
<https://www.rfc-editor.org/info/rfc5701>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
"Dissemination of Flow Specification Rules for IPv6",
RFC 8956, DOI 10.17487/RFC8956, December 2020,
<https://www.rfc-editor.org/info/rfc8956>.
11.2. Informative References
[I-D.ietf-idr-flowspec-l2vpn]
Hao, W., Eastlake, D. E., Litkowski, S., and S. Zhuang,
"BGP Dissemination of L2 Flow Specification Rules", Work
in Progress, Internet-Draft, draft-ietf-idr-flowspec-
l2vpn-19, 18 April 2022, <https://www.ietf.org/archive/id/
draft-ietf-idr-flowspec-l2vpn-19.txt>.
[I-D.li-apn-problem-statement-usecases]
Li, Z., Peng, S., Voyer, D., Xie, C., Liu, P., Qin, Z.,
and G. Mishra, "Problem Statement and Use Cases of
Application-aware Networking (APN)", Work in Progress,
Internet-Draft, draft-li-apn-problem-statement-usecases-
06, 7 March 2022, <https://www.ietf.org/archive/id/draft-
li-apn-problem-statement-usecases-06.txt>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<https://www.rfc-editor.org/info/rfc2780>.
[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
May 2010, <https://www.rfc-editor.org/info/rfc5871>.
Peng, et al. Expires 31 October 2022 [Page 17]
Internet-Draft APN FlowSpec Dissemination April 2022
[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>.
Authors' Addresses
Shuping Peng
Huawei Technologies
Beijing
China
Email: pengshuping@huawei.com
Zhenbin Li
Huawei Technologies
Beijing
China
Email: lizhenbin@huawei.com
Sheng Fang
Huawei Technologies
Beijing
China
Email: fangsheng@huawei.com
Yong Cui
Tsinghua University
Beijing
China
Email: cuiyong@tsinghua.edu.cn
Peng, et al. Expires 31 October 2022 [Page 18]