Export of Multiple Encapsulation Layer Information in IPFIX

Introduction A packet may have multi-layer network encapsulations, and each layer may use the same or different network encapsulation headers. e.g, IP in IP encapsulation , which is an IP tunneling mechanism that encapsulates one IP packet in another IP packet, typical IP-in-IP scenario includes IPv4-in-IPv4, IPv6-in-IPv6, IPv4-in-IPv6 and IPv6-in-IPv4. With the deployment of SRv6, the appearance of packets with IPv4-in-IPv6 or IPv6-in-IPv6 encapsulation becomes more and more common in the network. And there may be more than two network encapsulation layers in one packet as analyzed in section 3.1. When monitoring a traffic flow with multiple encapsulations, e.g IP-in-IP, a typical use case is to answer the following questions:

Which tunnel are the packets steered into (e.g, identified by the outmost IP header) ?
What are the details of the inner packet (e.g, identified by the innermost IP header) ?

However, based on the existing IPFIX mechanisms, it is not easy to differentiate between IEs of different encapsulation layers. This document aims to solve this problem by updating and introducing new IPFIX IEs for encapsulation layer indication. [Editor's Note]This version provides two alternative options to indicate the encapsulation layer information for discussion.

Terminology 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 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in , and . The following terms are used as defined in :

IPFIX
IPFIX Information Elements
Template
Collector
IPFIX Device

The following terms are used as defined in :

Segment Routing (SR)
Segment List
SRv6
BSID

The following terms are used as defined in :

Use Cases and Requirements

Use Cases There may be more than two network encapsulation layers in one packet. As shown in the figure below. CE1 sends IPv6 packets to CE2. Packet leaving CE1: IPv6<SA=CE1,DA=CE2> PE1 performs SRv6 function H.Encaps with SRv6 Policy, and the corresponding SID list is <SID-R1,SID-T1,SID-PE2>, wherein SID-T1 is a BSID initiated on node T1. Packet leaving PE1: IPv6<SA=PE1,DA=SID-R1><SID-R1,SID-T1,SID-PE2>IPv6<SA=CE1,DA=CE2> When the packet arrives at T1, based on BSID SID-T1 , T1 performs End.B6.Encaps and encapsulate the third IPv6 header onto the packet with the corresponding SID list <SID-R2,SID-R3>. Packet leaving T1:IPv6<SA=T1,DA=R2><SID-R2,SID-R3>IPv6<SA=PE1,DA=SID-PE2>lt;SID-R1,SID-T1,SID-PE2>IPv6<SA=CE1,DA=CE2> So the packet observed at node R2 has three IPv6 headers in it. Based on different goals of the network monitor, the data collection scenario may include one of the following:

The network monitor wants to collect the information of the outmost SRH and the inner SRH of the same packet.
The network monitor only wants to collect the information of the outmost IPv6 header.
The network monitor only wants to collect the information of the innermost IPv6 header.
The network monitor wants to collect the SA of the outmost IPv6 header (i.e., the starting point of the tunnel) and the DA of the innermost IPv6 header(i.e., the final destination of the packet)

Requirements Based on the scenarios described in section 3.1, the information collection requirements in IPFIX for multi-layer encapsulated packets include:

Req-a: Collecting the same fields from both the outer and inner packet headers at the same time.
Req-b: Collecting only the fields from the inner packet header.
Req-c: Collecting only the fields from the outer packet header
Req-d: Collecting different fields from the outer and inner packet headers at the same time.

For Req-a, specifies that, if an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process, but it can not be guaranteed that all the implementations follow this rule since there is not a "MUST" in the specification in .

Updates to RFC 7011 This document updates section 8 of by specifying mandatory rules when an Information Element is required more than once in a Template. The rules are: If an Information Element is required more than once in a Template, the different occurrences of this Information Element MUST follow the logical order of their treatments by the Metering Process. For example, if a selected packet goes through two hash functions, and if the two hash values are sent within a single Template, the first occurrence of the hash value must belong to the first hash function in the Metering Process. For example, when exporting the two source IP addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address Information Element occurrence must be the IPv4 address of the outer header, while the second occurrence must be the address of the inner header. Collecting Processes MUST properly handle Templates with multiple identical Information Elements.

IPFIX IEs for Encapsulation Layer Information In the following subsections, two options are provided for encapsulation layer indication:

Option 1: New IEs are defined as the layer separators. The meaning of the IEs of Header Fields (in other words, which encapsulation layer these IEs belongs to), depends on the appearance and the content of the "layer separator" IEs.
Option 2: A new IE using the data type "subTemplateMultiList" is defined to carry the multiple encapsulation packet header fields as the structured data. This method avoids the dependencies between IEs.

IPFIX Encapsulation Layer Information Option 1 This section defines several Encapsulation Layer IEs for network encapsulation layer indication. When there is no need to differentiate between these IEs in this document, they will be collectively referred to as "encapsulation layer IE".

encapLayerTop A new IE "encapLayerTop" is defined in this section to indicate which IEs in the IPFIX messages belongs to the outmost network encapsulation layer.

Name:: encapLayerTop
ElementID:: TBD1
Description:: A 16-bit identifier indicating that the IEs that follow immediately after it till the next Encapsulation Layer IE belong to the outmost network encapsulation layer (e.g, from the outmost Ethernet header to the first IP header). If there's not any other Encapsulation Layer IE exists in the Template, it means that all the IEs following encapLayerTop belong to the outmost network encapsulation layer. This IE has a fixed value of 0xFFFF.
Abstract Data Type:: unsigned16
Data Type Semantics:: identifier
Reference:: This document.

encapLayer2 A new IE "encapLayer2" is defined in this section to indicate which IEs in the IPFIX messages belongs to the second network encapsulation layer.

Name:: encapLayer2
ElementID:: TBD2
Description:: A 16-bit identifier indicating that the IEs that follow immediately after it till the next Encapsulation Layer IE belong to the second network encapsulation layer. If there's not any other Encapsulation Layer IE exists in the Template, it means that all the IEs following encapLayer2 belong to the second network encapsulation layer. This IE has a fixed value of 0xFFFF.
Abstract Data Type:: unsigned16
Data Type Semantics:: identifier
Reference:: This document.

encapLayer3 A new IE "encapLayer3" is defined in this section to indicate which IEs in the IPFIX messages belongs to the third network encapsulation layer.

Name:: encapLayer3
ElementID:: TBD3
Description:: A 16-bit identifier indicating that the IEs that follow immediately after it till the next Encapsulation Layer IE belong to the third network encapsulation layer. If there's not any other Encapsulation Layer IE exists in the Template, it means that all the IEs following encapLayer3 belong to the third network encapsulation layer. This IE has a fixed value of 0xFFFF.
Abstract Data Type:: unsigned16
Data Type Semantics:: identifier
Reference:: This document.

IPFIX for Encapsulation Layer Information Option 2 A new IE "multiLayerEcapFields" is defined in this section as shown below. This IE supports to carry the header fields for packets with multiple layers of encapsulation.

Name:

multiLayerEcapFields

ElementID:

TBA1

Description:

An IPFIX Information Element that denotes that the header fields of different encapsulation layers will be exported. Each top-level element in a subTemplateMultiList Information Element carries a Template ID, Length, and zero or more Data Records corresponding to the Template ID. The "ordered" structured data type semantic is used. The Length field of this subTemplateMultiList is encoded in three bytes even though it may be less than 255 octets.
The template IDs from top to bottom carried in the IE correspond to encapsulation layers of the packet flow, starting from the outermost layer. For example, the data record of the template whose template ID is carried in the first list element belongs to the outmost network encapsulation layer, the data record of the template whose template ID is carried in the second list element belongs to the second network encapsulation layer, and the data record of the template whose template ID is carried in the third list element belongs to the third network encapsulation layer.
If not all of the encapsulation layers are required to be exported, e.g., only the information of layer 1 and layer 3 need to be exported, the template ID in the data record and the corresponding length field MUST be set to 0 to indicate the absence of the information of this layer.

Abstract Data Type:

subTemplateList

Data Type Semantics:

list

Reference:

This document.

An example of the encoding of the IE "multiLayerEcapFields" is shown below for a traffic flow with IPv6-in-IPv6-in-IPv6 encapsulation, where the destination address of the outmost IPv6 header and the source address of the innermost IPv6 header are required to be exported, while the information of the second IPv6 header is not needed.

Encoding multiLayerEcapFields, Template for Flow Record

Template for the outmost IPv6 header

Template for the third IPv6 header

Encoding multiple-layer headers, Data Set

Operational Considerations It should be noticed that the layer information on different exportors may be different, since the networking context might be different from each exporter and each exporter only knows the layer information locally.

Operational Considerations for Option 1 To generate Flow Records with IEs for encapsulation layer included, the metering process SHOULD recognize the encapsulation layer of the corresponding fields in the packet. This is mainly based on local implementation and the details are out of the scope of this document. The order of the IEs in the Template Records MUST be guaranteed when using encapLayerTop/encapLayer2/encapLayer3, that is, the IEs belonging to each encapsulation layer MUST immediately follow the corresponding encapsulation layer IE. Each encapsulation layer IE SHALL NOT appear more than once in a Template. If there's more than one encapsulation layer IE of the same type in the Template, the Collecting Process MUST ignore the Template and the Collecting Process SHOULD log the error. As in , the Information Elements are derived from fields of packets or from packet treatment. For IEs that are not related with header fields, whether they are covered by scope of the encapsulation layer IE, they SHOULD be processed following the existing specifications. For IEs of Header Fields that are not in the scope of encapsulation layer IE, e.g, there're IEs of Header Fields in the Template before the appearance of Encapsulation Layer IEs, they SHOULD be processed properly based on the default behavior of the Collector, how the Collector would process them is out of the scope of this document. Currently only three IEs are defined to meet the traffic monitoring requirements for packets of no more than three layers. If in the future , there're packets with four or five or more encapsulation layers in the network and the packet header information of each layer is required to be exported, more new IEs such as encapLayer4/encapLayer5 MAY be needed

Operational Considerations for Option 2 Beside the templateId 0, if the templateId used by the multiLayerEcapFields IE in the data record doesn't exist, the collector SHOULD ingore the encapsulation layer this templateId represents and log an error, and it is RECOMMENDED to process the information of other layers normally. For IEs of Header Fields that are not included the multiLayerEcapFields IE, they SHOULD be processed properly based on the default behavior of the Collector, how the Collector would process them is out of the scope of this document. As in , the Information Elements are derived from fields of packets or from packet treatment. For IEs that are not related with header fields, whether they are included in the encapsulation layer IE, they SHOULD be processed following the existing specifications.

Security Considerations There are no additional security considerations regarding allocation of these new IPFIX IEs compared to .

IANA Considerations For option 1, this document requests IANA to create new IEs under the "IPFIX Information Elements" registry available at . For option 2, this document requests IANA to create new IEs under the "IPFIX Information Elements" registry available at .

Acknowledgements The authors would like to thank Benoit Claise and Thomas Graf for their helpful comments and suggestions.