| Internet-Draft | APN FlowSpec Dissemination | October 2021 |
| Peng, et al. | Expires 28 April 2022 | [Page] |
A 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 (incl. 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 on 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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
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 28 April 2022.¶
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 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.¶
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 allows to convey 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. In an IPv6 network, a design proposal of such structured value can refer to [I-D.li-6man-app-aware-ipv6-network]. The APN attribute can be encapsulated in various data plane 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 altogether 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. Currently, there is still 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.¶
APN: Application-aware Networking¶
APN ID: APN Identifier¶
Flow Spec: Flow Specification¶
BGP-FS: Border Gateway Protocol (BGP) Flow Specification (FS)¶
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
¶
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.¶
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 in the Flow Spec.¶
type (1 octet): This indicates the new component type TBD1, to be assigned by IANA.¶
length (1 octet): This indicates the length of the mask or 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.¶
Since the APN ID is a structured value, the mask in the Flow Spec is used to enable the 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, i.e. 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.¶
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
¶
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 Section 6.¶
More than one Flow Specification rule condition 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 are 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.¶
Therefore, the ordering of the Flow Spec rules for APN needs to be clearly specified.¶
In this document, in order to accompany the Flow Spec rules, 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 these Flow Spec rules.¶
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
¶
The following principles are defined.¶
1. Within a sub-group, the order is the same as the previously defined.¶
2. Between sub-groups, the sub-group is ordered with 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 is any sub-group left.¶
3. Between groups, the group is ordered with 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 and the evaluation of the following group(s) will not start.¶
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.¶
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 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----------------------------------------------------------
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
¶
+==================+=====================+========================+
| 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 |
+------------------+---------------------+------------------------+
¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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.¶
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.¶
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.¶
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.¶
The stitch-apn Extended Community instructs a system to use the Bitmask to "and" operate on the existing APN ID of a transiting IP packet and get the part to be further encapsulated, and then negate the Bitmask to "and" operate on 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.¶
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.¶
The APN ID is identified by an 1-octet component type (TBD1), and it will be added to the IANA registry entitled "Flow Spec Component Types".¶
+=======+====================+===========+
| Value | Name | Reference |
+=======+====================+===========+
| TBD1 | APN ID | This ID |
+-------+--------------------+-----------+
¶
The Grouping Identifier Opaque Extended Community is defined in this document and a Sub-Type = TBD2 needs to be assigned.¶
+=======+======================+===========+
| Value | Name | Reference |
+=======+======================+===========+
| TBD2 | Grouping Identifier | This ID |
+-------+----------------------+-----------+
¶
The Extended Community Flow Specification Actions are defined in this document and corresponding Sub-Types as shown in the following table need to be assigned.¶
+============+==============================+===========+
| Sub-Type | Name | Reference |
| Value | | |
+============+==============================+===========+
| TBD3 | traffic-marking-apn | This ID |
+------------+------------------------------+-----------+
| TBD4 | traffic-marking-apn-partial | This ID |
+------------+------------------------------+-----------+
| TBD5 | inherit-apn | This ID |
+------------+------------------------------+-----------+
| TBD6 | stitch-apn | This ID |
+------------+------------------------------+-----------+
¶
The authors would like to thank the careful reviews and valuable comments from Haibo Wang, Shunwan Zhuang, and Stefano Previdi.¶
The security considerations are the same as [RFC8955], [RFC8956], and [I-D.li-apn-framework].¶