Internet-Draft APN Header April 2022
Li, et al. Expires 10 October 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-li-apn-header-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Li
Huawei Technologies
S. Peng
Huawei Technologies
S. Zhang
China Unicom

Application-aware Networking (APN) Header

Abstract

This document defines the application-aware networking (APN) header which can be used in a variety of data planes.

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 10 October 2022.

Table of Contents

1. Introduction

Application-aware Networking (APN) is introduced in [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. APN conveys an attribute with data packets in the network and makes the network aware of fine-grain requirements at the user group and application group levels.

Such an attribute is acquired, constructed in a structured value, and then encapsulated in the packets. Such a structured value is treated as an opaque object in the network, to which the network operator applies policies in various nodes/service functions along the path and provides corresponding services.

This structured attribute can be encapsulated in various data planes adopted within a Network Operator's controlled and limited domain, e.g. MPLS, VXLAN, SR/SRv6 and other tunnel technologies, which waits to be further specified.

This document defines the application-aware networking (APN) header which can be used in different data planes. The typical data planes include the MPLS data plane and IPv6 data plane..

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 Attribute: Application-aware Networking Attribute, including APN ID and APN Parameters. It can be added at the edge devices of an APN domain along with the tunnel encapsulation.

APN ID: Application-aware Networking ID, including Application Group ID and User Group ID.

APN Para: Application-aware Networking Parameters, e.g., network performance parameters.

4. Application-aware Networking Header

A common header is defined and can be used in different data planes. The common header carries the APN attribute that is composed of APN ID and APN parameters.

This document defines three types of APN ID:

- Type 1 APN ID: it is 32 bits.

- Type 2 APN ID: it is 64 bits.

- Type 3 APN ID: it is 128 bits.

According to the types of APN ID, three types of APN headers are defined.

Type 1 APN Header:

 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-Type  |     Flags     |         APN-Para-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             APN-ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Intent (Optional)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       APN-Para (Optional)                     |
                             ......
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1. APN Header with Type 1 APN ID

In this type of APN Header, the length of the APN ID is 32 bits.

APN-ID-Type: An 8-bit identifier, indicates the type of APN ID.

Flags: An 8-bit field. The possible flags will be defined in the future versions of this document.

APN-Para-Type: A 16-bit map that specifies which APN parameters are specified for the APN ID. The APN-Para-Type value is a bitmap. The packing order of the APN parameters follows the bit order as specified in the APN-Para-Type bitmap field. The following bits are defined in this document, with details on each bit described in Section 6.

Bit 0 (Most significant bit) When set, indicates the presence of the bandwidth requirement.

Bit 1 When set, indicates the presence of the delay requirement.

Bit 2 When set, indicates the presence of the jitter requirement.

Bit 3 When set, indicates the presence of the packet loss rate requirement.

APN-ID: A 32-bit identifier.

Intent: A 32-bit identifier, represents a set of service requirements to the network.

APN-Para: A variable field including APN parameters. The presence of the APN parameters is indicated by the APN-Para-Type.

Type 2 APN Header

 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-Type  |     Flags     |         APN-Para-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             APN-ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Intent (Optional)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       APN-Para (Optional)                     |
                             ......
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2. APN Header with Type 2 APN ID

In this type of APN Header, the length of the APN ID is 64 bits.

APN-ID-Type: An 8-bit identifier, indicates the type of APN ID.

Flags: An 8-bit field. The possible flags will be defined in the future versions of this document.

APN-Para-Type: A 16-bit map which specifies which APN parameters are specified for the APN ID. The following bits are defined in this document, with details on each bit described in the Section 6. The order of packing the data fields in each node data element follows the bit order of the APN-Para-Type field, as follows:

Bit 0 (Most significant bit) When set, indicates the presence of the bandwidth requirement.

Bit 1 When set, indicates the presence of the delay requirement.

Bit 2 When set, indicates the presence of the jitter requirement.

Bit 3 When set, indicates the presence of the packet loss rate requirement.

APN-ID: A 64-bit identifier.

Intent: A 32-bit identifier, represents a set of service requirements to the network.

APN-Para: A variable field including APN parameters. The presence of the APN parameters is indicated by the APN-Para-Type.

Type 3 APN Header

 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-Type  |     Flags     |         APN-Para-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             APN-ID                            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Intent (Optional)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       APN-Para (Optional)                     |
                             ......
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3. APN Header with Type 3 APN ID

In this type of APN Header, the length of the APN ID is 128 bits.

APN-ID-Type: An 8-bit identifier, indicates the type of APN ID.

Flags: An 8-bit field. The possible flags will be defined in the future versions of this document.

APN-Para-Type: A 16-bit map which specifies which APN parameters are specified for the APN ID. The following bits are defined in this document, with details on each bit described in the Section 6. The order of packing the data fields in each node data element follows the bit order of the APN-Para-Type field, as follows:

Bit 0 (Most significant bit) When set, indicates the presence of the bandwidth requirement.

Bit 1 When set, indicates the presence of the delay requirement.

Bit 2 When set, indicates the presence of the jitter requirement.

Bit 3 When set, indicates the presence of the packet loss rate requirement.

APN-ID: A 128-bit identifier.

Intent: A 32-bit identifier, represents a set of service requirements to the network.

APN-Para: A variable field including APN parameters. The presence of the APN parameters is indicated by the APN-Para-Type.

5. APN ID

The APN ID can be divided into three parts:

APP-Group-ID: Application Group ID

USER-Group-ID: User Group ID

Reserved: The reserved field.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      APP-Group-ID     |    USER-Group-ID    |    Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4. Structure of APN-ID

The lengths of the APP-Group-ID and the USER-Group-ID are variable. Their lengths must be configured and consistent within a specific APN domain.

6. APN Parameters

In the APN Header, the APN-Para-Type is a bit field to indicate the presence of corresponding APN parameters. When the bit is set, the corresponding APN parameter MUST exist in the APN Header. The length of each APN parameter is 32 bits. Thus it is easy to skip over unknown requirements.

Typical APN parameters are the parameters related with the network performance requirements as follows:

1. Bandwidth Requirement

This Bandwidth Requirement parameter indicates the minimum acceptable bandwidth for the APN traffic. The format of this parameter is shown in the following diagram:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Bandwidth                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5. Bandwidth Requirement Parameter

where:

Bandwidth: This 32-bit unsigned integer field carries the bandwidth requirement in Mbps along the path.

2. Delay Requirement

This Delay Requirement parameter indicates the maximum acceptable delay. The format of this parameter is shown in the following diagram:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    RESERVED   |                   Delay                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 6. Delay Requirement Parameter

where:

RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.

Delay: This 24-bit field carries the delay requirements in microseconds, encoded as an unsigned integer value. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is not constrained. This value is the highest delay that can be tolerated.

3. Delay Variation Requirement

This Delay Variation Requirement parameter indicates the maximum acceptable delay variation. The format of this parameter is shown in the following diagram:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESERVED     |               Delay Variation                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 7. Delay Variation Parameter

where:

RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.

Delay Variation: This 24-bit field carries the delay variation requirements in microseconds, encoded as an unsigned integer value.

4. Packet Loss Rate Requirement

This Packet Loss Rate Requirement parameter indicates the maximum acceptable packet loss rate. The format of this parameter is shown in the following diagram:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    RESERVED   |                    Packet Loss Rate           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 8. Packet Loss Rate Sub-TLV

where:

RESERVED: This field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.

Packet Loss Rate: This 24-bit field carries packet loss rate requirement in packets per second as an unsigned integer. This value is the highest packet-loss rate that can be tolerated.

7. IANA Considerations

These IANA Considerations conform to [RFC8126].

IANA is requested to create the following new registries on a new "Application-Aware Networking (APN)" webpage.

7.1. APN ID Types

IANA is requested to create the following registry on the Application-Aware Networking (APN) Attribute webpage:

Name: APN ID Types

Registration Procedure: IETF Review

Reference: [this document]


   Value    Description     Reference
   -----   -------------   ---------------
       0    reserved
       1    Type 1 APN ID   [this document]
       2    Type 2 APN ID   [this document]
       3    Type 3 APN ID   [this document]
   4-254    unassigned
     255    reserved

7.2. APN Parameter Types

IANA is requested to create the following registry on the Application-Aware Networking (APN) Attribute webpage:

Name: APN Parameter Types

Registration Procedure: IETF Review

Reference: [this document]


   Bit    Description               Reference
   ---   -----------------------   ---------------
     0   Bandwidth requirement     [this document]
     1   Delay requirement         [this document]
     2   Jitter requirement        [this document]
     3   Packet loss requirement   [this document]
  4-15   unassigned

8. Acknowledgements

The suggestions of the following are gratefully acknowledged: Stefano Previdi, Adrian Farrel, Donald Eastlake.

9. Security Considerations

The Security Considerations described in [I-D.li-apn-problem-statement-usecases] and [I-D.peng-apn-security-privacy-consideration] can be referred to.

10. References

10.1. Normative References

[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, , <https://www.ietf.org/archive/id/draft-li-apn-framework-05.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[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, , <https://www.ietf.org/archive/id/draft-li-apn-problem-statement-usecases-06.txt>.
[I-D.peng-apn-security-privacy-consideration]
Peng, S., Li, Z., Voyer, D., Li, C., Liu, P., and C. Cao, "APN Security and Privacy Considerations", Work in Progress, Internet-Draft, draft-peng-apn-security-privacy-consideration-02, , <https://www.ietf.org/archive/id/draft-peng-apn-security-privacy-consideration-02.txt>.
[RFC3272]
Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, , <https://www.rfc-editor.org/info/rfc3272>.

Authors' Addresses

Zhenbin Li
Huawei Technologies
Beijing
100095
China
Shuping Peng
Huawei Technologies
Beijing
100095
China
Shuai Zhang
China Unicom
Beijing
China

mirror server hosted at Truenetwork, Russian Federation.