rfc9263xml2.original.xml   rfc9263.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocompact="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc tocdepth="3"?> <!ENTITY wj "&#8288;">
<?rfc tocindent="yes"?> ]>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-sfc-nsh-tlv-15">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sfc-nsh-tlv- 15" number="9263" submissionType="IETF" category="std" consensus="true" ipr="tru st200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" s ymRefs="true" sortRefs="true" version="3">
<front> <!-- xml2rfc v2v3 conversion 3.12.5 -->
<title abbrev="NSH MD2 Context Headers">Network Service Header (NSH) Meta
data Type 2 Variable-Length Context Headers</title>
<author fullname="Yuehua Wei" initials="Yuehua" role="editor" surna <front>
me="Wei"> <title abbrev="NSH MD2 Context Headers">Network Service Header (NSH) Metadat
a Type 2 Variable-Length Context Headers</title>
<seriesInfo name="RFC" value="9263"/>
<author fullname="Yuehua Wei" initials="Y." surname="Wei" role="editor">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street>No.50, Software Avenue</street>
<street>No.50, Software Avenue</street> <city>Nanjing</city>
<region/>
<city>Nanjing</city> <code>210012</code>
<country>China</country>
<region/>
<code>210012</code>
<country>China</country>
</postal> </postal>
<email>wei.yuehua@zte.com.cn</email> <email>wei.yuehua@zte.com.cn</email>
</address> </address>
</author> </author>
<author initials="U." surname="Elzur" fullname="Uri Elzur">
<author initials="U." surname="Elzur" fullname="Uri Elzur"> <organization>Intel</organization>
<organization>Intel</organization> <address>
<address> <email>uri.elzur@intel.com</email>
<email>uri.elzur@intel.com</email> </address>
</address> </author>
</author> <author initials="S." surname="Majee" fullname="Sumandra Majee">
<organization>Individual Contributor</organization>
<author initials="S." surname="Majee" fullname="Sumandra Majee"> <address>
<organization>Individual contributor</organization> <email>Sum.majee@gmail.com</email>
<address> </address>
<email>Sum.majee@gmail.com</email> </author>
</address> <author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
</author> <organization>Cisco</organization>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro"> <address>
<organization>Cisco</organization> <email>cpignata@cisco.com</email>
<address> </address>
<email>cpignata@cisco.com</email> </author>
</address> <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake, 3
</author> rd">
<author initials="D." surname="Eastlake" fullname="Donald E. Eastlake"> <organization>Futurewei Technologies</organization>
<organization>Futurewei Technologies</organization> <address>
<address> <postal>
<postal> <street>2386 Panoramic Circle</street>
<street>2386 Panoramic Circle</street> <city>Apopka</city>
<city>Apopka</city> <region>FL</region>
<region>FL</region> <code>32703</code>
<code>32703</code> <country>United States of America</country>
<country>USA</country> </postal>
</postal> <phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email> <email>d3e3e3@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022"/> <date year="2022" month="August"/>
<area>RTG</area>
<area>Routing</area> <workgroup>SFC</workgroup>
<keyword>SFC metadata</keyword>
<workgroup>Service Function Chaining Working Group</workgroup> <abstract>
<t>
<abstract> Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 83
<t> 00) to steer and provide context metadata (MD) with each packet. Such metadata c
Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 83 an be of various types, including MD Type 2, consisting of Variable-Length Conte
00) to steer and provide context Metadata (MD) with each packet. Such Metadata c xt Headers. This document specifies several such Context Headers that can be use
an be of various Types including MD Type 2 consisting of variable length context d within a Service Function Path (SFP).
headers. This document specifies several such context headers that can be used </t>
within a service function path. </abstract>
</t> </front>
</abstract> <middle>
</front> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<middle> <t>
<section anchor="intro" title="Introduction"> The Network Service Header (NSH) <xref target="RFC8300" format="default"/> is
<t> the
The Network Service Header (NSH) <xref target="RFC8300"/> is the Service Function Chaining (SFC) encapsulation that supports the SFC architect
Service Function Chaining (SFC) encapsulation that supports the SFC architect ure <xref target="RFC7665" format="default"/>. As such, the NSH provides the fo
ure <xref target="RFC7665"/>. As such, the NSH provides following key elements: llowing key elements:
<list style="numbers"> </t>
<t>Service Function Path (SFP) identification.</t> <ol spacing="normal" type="1">
<t>Indication of location within a Service Function Path.</t> <li>Service Function Path (SFP) identification</li>
<t>Optional, per-packet metadata (fixed-length or variable-length).</t> <li>indication of location within an SFP</li>
</list> <li>optional, per-packet metadata (fixed-length or variable-length)</li>
</t> </ol>
<t> <t>
<xref target="RFC8300"/> further defines two metadata formats (MD Types): 1 <xref target="RFC8300" format="default"/> further defines two metadata forma
and 2. MD ts (MD Types): 1 and 2. MD
Type 1 defines the fixed-length, 16-octet long metadata, whereas MD Type 2 Type 1 defines the fixed-length, 16-octet metadata, whereas MD Type 2
defines a variable-length context format for metadata. This document defines defines a variable-length context format for metadata. This document defines
several common metadata context headers for use within NSH MD Type 2. These sup several common metadata Context Headers for use within NSH MD Type 2.
plement the Subscriber Identity and Performance Policy MD Type 2 metadata contex These supplement the Subscriber Identifier and Performance Policy MD Type 2 m
t headers specified in <xref target="RFC8979"/>. etadata Context Headers specified in <xref target="RFC8979" format="default"/>.
</t> </t>
<t> <t>
This document does not address metadata usage, updating/chaining of This document does not address metadata usage, updating/chaining of
metadata, or other SFP functions. Those topics are described in <xref target metadata, or other SFP functions. Those topics are described in <xref target
="RFC8300"/>. ="RFC8300" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions used in this document"> <name>Conventions Used in This Document</name>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>This document uses the terminology defined in the SFC architecture <x
<t>This document uses the terminology defined in the SFC Architectur ref target="RFC7665" format="default"/> and the NSH <xref target="RFC8300" forma
e <xref target="RFC7665"/> and the Network Service Header <xref target="RFC8300" t="default"/>.</t>
/>.</t>
</section>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section anchor="nsh-t2-format-sec" title="NSH MD Type 2 format"> <name>Requirements Language</name>
<t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section>
<section anchor="nsh-t2-format-sec" numbered="true" toc="default">
<name>NSH MD Type 2 Format</name>
<t>
An NSH is composed of a 4-octet Base Header, a 4-octet Service Path An NSH is composed of a 4-octet Base Header, a 4-octet Service Path
Header and optional Context Headers. The Base Header identifies the MD-Type Header, and optional Context Headers. The Base Header identifies the MD Type
in use: in use:
<figure align="center" anchor="nsh-base-hdr-fig" title="NSH Base He </t>
ader"> <figure anchor="nsh-base-hdr-fig">
<artwork><![CDATA[ <name>NSH Base Header</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
Please refer to NSH <xref target="RFC8300"/> for a detailed header description <t>
. Please refer to the NSH <xref target="RFC8300" format="default"/> for a detail
ed header description.
</t> </t>
<t> <t>
When the base header specifies MD Type = 0x2, zero or more Variable When the Base Header specifies MD Type = 0x2, zero or more Variable-Length Co
Length Context Headers MAY be added, immediately following the ntext Headers <bcp14>MAY</bcp14> be added, immediately following the
Service Path Header. <xref target="nsh-tlv-fig"/> below depicts the format of Service Path Header. <xref target="nsh-tlv-fig" format="default"/> below depi
the Context Header cts the format of the Context Header
as defined in Section 2.5.1 of <xref target="RFC8300"/>. as defined in <xref target="RFC8300" section="2.5.1" sectionFormat="of" forma
<figure align="left" anchor="nsh-tlv-fig" title="NSH Variable-Length Context t="default"/>.
Headers"> </t>
<artwork><![CDATA[ <figure anchor="nsh-tlv-fig">
0 1 2 3 <name>NSH Variable-Length Context Headers</name>
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 <artwork name="" type="" align="center" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Metadata Class | Type |U| Length | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable-Length Metadata | | Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable-Length Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</t> </figure>
</section> </section>
<section anchor="nsh-tlvs-sec" numbered="true" toc="default">
<section anchor="nsh-tlvs-sec" title="NSH MD Type 2 Context Headers"> <name>NSH MD Type 2 Context Headers</name>
<t>
<t> <xref target="RFC8300" format="default"/> specifies Metadata Class 0x0000 as
<xref target="RFC8300"/> specifies Metadata Class 0x0000 as IETF Base NSH MD IETF Base NSH MD Class. In this document, metadata types are defined for the IE
Class. In this document, metadata types are defined for the IETF Base NSH MD Cl TF Base NSH MD Class. The Context Headers specified in the subsections below are
ass. The Context Headers specified in the subsections below are as follows: as follows:
</t> </t>
<t>1. Forwarding Context</t> <ol spacing="normal">
<t>2. Tenant Identifier</t> <li> Forwarding Context</li>
<t>3. Ingress Network Node Information</t> <li> Tenant ID</li>
<t>4. Ingress Node Source Interface</t> <li> Ingress Network Node Information</li>
<t>5. Flow ID</t> <li> Ingress Node Source Interface</li>
<t>6. Source and/or Destination Groups</t> <li> Flow ID</li>
<t>7. Policy Identifier</t> <li> Source and/or Destination Groups</li>
<li> Policy ID</li>
<section anchor="fwd-context-sec" title="Forwarding Context"> </ol>
<t> <section anchor="fwd-context-sec" numbered="true" toc="default">
<name>Forwarding Context</name>
<t>
This metadata context carries a network forwarding context, used for This metadata context carries a network forwarding context, used for
segregation and forwarding scope. Forwarding context can take segregation and forwarding scope.
several forms depending on the network environment. For example, VXLAN/V Forwarding context can take
XLAN-GPE VNID, VRF identification, or VLAN. several forms depending on the network environment, for example, Virtual
eXtensible Local Area Network (VXLAN) / Generic Protocol Extension for
<figure align="left" anchor="fwd-context-fig1" title="VLAN Forwar VXLAN (VXLAN-GPE) Virtual Network Identifier (VNID), VPN Routing and Forw
ding Context"> arding (VRF) identification, or VLAN.</t>
<artwork><![CDATA[ <figure anchor="fwd-context-fig1">
0 1 2 3 <name>VLAN Forwarding Context</name>
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 <artwork name="" type="" align="center" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x0 | Reserved | VLAN ID | | Metadata Class = 0x0000 | Type = 0x04 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> |CT=0x0 | Reserved | VLAN ID |
</figure> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<figure align="left" anchor="fwd-context-fig2" title="QinQ Forwar
ding Context">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x1 |Resv | Service VLAN ID | Customer VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure align="left" anchor="fwd-context-fig3" title="MPLS VPN Fo
rwarding Context">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x2 | Reserved | MPLS VPN Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure align="left" anchor="fwd-context-fig4" title="VNI Forward
ing Context">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x3 | Resv | Virtual Network Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure align="left" anchor="fwd-context-fig5" title="Session ID Forward
ing Context">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA1 |U| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</t> <figure anchor="fwd-context-fig2">
<t> <name>QinQ Forwarding Context</name>
where: <artwork name="" type="" align="center" alt=""><![CDATA[
<list> 0 1 2 3
<t>Context Type (CT) is four bits-long field that defines the interpretat 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
ion of the Forwarding Context field. Please see the IANA Considerations in <xref +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
target="iana-fc-type"/>. This document defines these CT values: | Metadata Class = 0x0000 | Type = 0x04 |U| Length = 4 |
<list style="simbols"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>0x0 - 12 bits VLAN identifier <xref target="IEEE.802.1 |CT=0x1 |Resv | Service VLAN ID | Customer VLAN ID |
Q_2018"/>. See <xref target='fwd-context-fig1'/>. </t> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>0x1 - 24 bits double tagging identifiers. A service VL ]]></artwork>
AN tag followed by a customer VLAN tag <xref target="IEEE.802.1Q_2018"/>. The tw </figure>
o VLAN IDs are concatenated and appear in the same order that they appeared in t <figure anchor="fwd-context-fig3">
he payload. <name>MPLS VPN Forwarding Context</name>
See <xref target='fwd-context-fig2'/>.</t> <artwork name="" type="" align="center" alt=""><![CDATA[
<t>0x2 - 20 bits MPLS VPN label(<xref target="RFC3032"/>) 0 1 2 3
(<xref target="RFC4364"/>). See <xref target='fwd-context-fig3'/>.</t> 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
<t>0x3 - 24 bits virtual network identifier (VNI)<xref ta +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
rget="RFC8926"/>. See <xref target='fwd-context-fig4'/>. </t> | Metadata Class = 0x0000 | Type = 0x04 |U| Length = 4 |
<t>0x4 - 32 bits Session ID (<xref target="RFC3931"/>). T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
his is called Key in GRE <xref target="RFC2890"/>. See <xref target='fwd-context |CT=0x2 | Reserved | MPLS VPN Label |
-fig5'/>. </t> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</list> ]]></artwork>
Reserved (Resv) bits in the context fields MUST be sent a </figure>
s zero and ignored on receipt. <figure anchor="fwd-context-fig4">
</t> <name>VNI Forwarding Context</name>
</list> <artwork name="" type="" align="center" alt=""><![CDATA[
0 1 2 3
</t> 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
</section> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = 0x04 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x3 | Resv | Virtual Network Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<figure anchor="fwd-context-fig5">
<name>Session ID Forwarding Context</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = 0x04 |U| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are described as follows:</t>
<dl newline="false" spacing="normal">
<dt>Context Type (CT):</dt><dd><t>This 4-bit field that defines th
e interpretation of the Forwarding Context field. Please see the IANA considerat
ions in <xref target="iana-fc-type" format="default"/>. This document defines th
ese CT values:</t>
<dl newline="false" spacing="normal" indent="6">
<dt>0x0:</dt> <dd>12-bit VLAN identifier <xref target="IEEE.802
.1Q_2018" format="default"/>. See <xref target="fwd-context-fig1" format="defaul
t"/>. </dd>
<dt>0x1:</dt> <dd>24-bit double tagging identifiers. A service
VLAN tag followed by a customer VLAN tag <xref target="IEEE.802.1Q_2018" format=
"default"/>. The two VLAN IDs are concatenated and appear in the same order that
they appeared in the payload. See <xref target="fwd-context-fig2" format="defau
lt"/>.</dd>
<dt>0x2:</dt> <dd>20-bit MPLS VPN label <xref target="RFC3032"
format="default"/> <xref target="RFC4364" format="default"/>. See <xref target="
fwd-context-fig3" format="default"/>.</dd>
<dt>0x3:</dt> <dd>24-bit virtual network identifier (VNI) <xref
target="RFC8926" format="default"/>. See <xref target="fwd-context-fig4" format
="default"/>. </dd>
<dt>0x4:</dt> <dd>32-bit Session ID <xref target="RFC3931" form
at="default"/>. This is called Key in GRE <xref target="RFC2890" format="default
"/>. See <xref target="fwd-context-fig5" format="default"/>.</dd>
</dl>
</dd>
<dt>Reserved (Resv):</dt><dd>These bits in the context fields <bcp
14>MUST</bcp14> be sent as zero and ignored on receipt.</dd>
</dl>
<section anchor="tenant-sec" title="Tenant Identifier"> </section>
<t> <section anchor="tenant-sec" numbered="true" toc="default">
<name>Tenant ID</name>
<t>
Tenant identification is often used for segregation within a Tenant identification is often used for segregation within a
multi-tenant environment. Orchestration system-generated tenant multi-tenant environment. Orchestration system-generated Tenant
IDs are an example of such data. This context header carries the value of IDs are an example of such data. This Context Header carries the value of
the Tenant identifier. <xref target="OpenDaylight-VTN"/> Virtual Tenant Network the Tenant ID. Virtual Tenant Network (VTN) <xref target="OpenDaylight-VTN" for
(VTN) is an application that provides multi-tenant virtual network on an SDN co mat="default"/> is an application that provides multi-tenant virtual networks on
ntroller. a Software-Defined Networking (SDN) controller.
<figure align="left" anchor="tenant-fig" title="Tenant Identifier List"> </t>
<artwork><![CDATA[ <figure anchor="tenant-fig">
0 1 2 3 <name>Tenant ID List</name>
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 <artwork name="" type="" align="center" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Metadata Class = 0x0000 | Type = TBA2 |U| Length | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tenant ID ~ | Metadata Class = 0x0000 | Type = 0x05 |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Tenant ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</t> <t>The fields are described as follows:</t>
<dl newline="false" spacing="normal">
<t>The fields are described as follows: <dt>Length:</dt>
<list> <dd>Indicates the length of the Tenant ID in octets (see <xref target="
<t>Length: Indicates the length of the Tenant ID in octets (see Section RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
2.5.1 of <xref target="RFC8300"/>).</t> <dt>Tenant ID:</dt>
<dd>Represents an opaque value pointing to orchestration system-generat
<t>Tenant ID: Represents an opaque value pointing to Orchestration syst ed Tenant ID. The structure and semantics of this field are specific to the oper
em-generated tenant identifier. The structure and semantics of this field are sp ator's deployment across its operational domain and are specified and assigned b
ecific to the operator's deployment across its operational domain, and are speci y an orchestration function. The specifics of that orchestration-based assignmen
fied and assigned by an orchestration function. The specifics of that orchestrat t are outside the scope of this document.</dd>
ion-based assignment are outside the scope of this document.</t> </dl>
</list> </section>
</t> <section anchor="ingress-net-nodeid-sec" numbered="true" toc="default">
<name>Ingress Network Node Information</name>
</section> <t>
This Context Header carries a Node ID of the network node at which the pa
<section anchor="ingress-net-nodeid-sec" title="Ingress Network Node Informa cket entered the SFC-enabled domain. This node will necessarily be a classifier
tion"> <xref target="RFC7665" format="default"/>. In cases where the Service Path Ident
<t> ifier (SPI) identifies the ingress node, this Context Header is superfluous.
This context header carries a Node ID of the network node at which the pa </t>
cket entered the SFC-enabled domain. This node will necessarily be a Classifier <figure anchor="ingress-net-nodeid-fig">
<xref target="RFC7665"/>. In cases where the SPI identifies the ingress node, th <name>Ingress Network Node ID</name>
is context header is superfluous. <artwork name="" type="" align="center" alt=""><![CDATA[
<figure align="left" anchor="ingress-net-nodeid-fig" title="Ingress Netw 0 1 2 3
ork Node ID"> 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
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 | Metadata Class = 0x0000 | Type = 0x06 |U| Length |
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Node ID ~
| Metadata Class = 0x0000 | Type = TBA3 |U| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</t> <t>The fields are described as follows:</t>
<t> <dl newline="false" spacing="normal">
The fields are described as follows: <dt>Length:</dt>
<list> <dd>Indicates the length of the Node ID in octets (see <xref target="RF
<t>Length: Indicates the length of the Node ID in octets (see Section 2. C8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
5.1 of <xref target="RFC8300"/>).</t> <dt>Node ID:</dt>
<dd>Represents an opaque value of the ingress network Node ID. The stru
cture and semantics of this field are deployment specific. For example, Node ID
may be a 4-octet IPv4 address Node ID, a 16-octet IPv6 address Node ID, a 6-octe
t MAC address, an 8-octet MAC address (64-bit Extended Unique Identifier (EUI-64
)), etc.</dd>
</dl>
</section>
<t>Node ID: Represents an opaque value of the ingress network node ID. T <section anchor="ingress-net-sitf-sec" numbered="true" toc="default">
he structure and semantics of this field are deployment specific. For example, N <name>Ingress Network Source Interface</name>
ode ID may be a 4 octets IPv4 address Node ID, or a 16 octets IPv6 address Node <t>This context identifies the ingress interface of the ingress network
ID, or a 6 octets MAC address, or 8 octets MAC address (EUI-64), etc.</t> node. The l2vlan (135), l3ipvlan (136), ipForward (142), and mpls (166) in <xref
</list> target="IANAifType" format="default"/> are examples of source interfaces.
</t> </t>
</section> <figure anchor="ingress-net-sitf-fig">
<name>Ingress Network Source Interface</name>
<section anchor="ingress-net-sitf-sec" title="Ingress Network Source Interface"> <artwork name="" type="" align="center" alt=""><![CDATA[
<t>This context identifies the ingress interface of the ingress network node. Th 0 1 2 3
e l2vlan (135), l3ipvlan (136), ipForward (142), mpls (166) in <xref target="IAN 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
AifType"/> are examples of source interfaces. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<figure align="left" anchor="ingress-net-sitf-fig" title="Ingress Network Source | Metadata Class = 0x0000 | Type = 0x07 |U| Length |
Interface"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<artwork><![CDATA[ ~ Source Interface ~
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA4 |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Interface ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</t> </figure>
<t>The fields are described as follows: <t>The fields are described as follows:</t>
<list> <dl newline="false" spacing="normal">
<t>Length: Indicates the length of the Source Interface in octets (see Se <dt>Length:</dt>
ction 2.5.1 of <xref target="RFC8300"/>).</t> <dd>Indicates the length of the Source Interface in octets (see <
<t>Source Interface: Represents an opaque value of identifier of the ingress xref target="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</d
interface of the ingress network node.</t> d>
</list> <dt>Source Interface:</dt>
</t> <dd>Represents an opaque value of the identifier of the ingress i
</section> nterface of the ingress network node.</dd>
</dl>
<section anchor="flow-id-sec" title="Flow ID"> </section>
<t> <section anchor="flow-id-sec" numbered="true" toc="default">
Flow ID provides a field in the NSH MD Type 2 to label packets belonging to <name>Flow ID</name>
the same flow. For example, <xref target="RFC8200"/> defined IPv6 Flow Label as <t>
Flow ID, <xref target="RFC6790"/> defined an entropy label which is generated ba Flow ID provides a field in NSH MD Type 2 to label packets belonging to the
sed on flow information in the MPLS network is another example of Flow ID. Absen same flow. For example, <xref target="RFC8200" format="default"/> defines IPv6 F
ce of this field, or low Label as Flow ID. Another example of Flow ID is how <xref target="RFC6790" f
ormat="default"/> defines an entropy label that is generated based on flow infor
mation in the MPLS network. Absence of this field or
a value of zero denotes that packets have not been labeled with a Flow ID. a value of zero denotes that packets have not been labeled with a Flow ID.
</t> </t>
<t> <figure anchor="flow-id-ipv6-fig1">
<figure align="left" anchor="flow-id-ipv6-fig1" title="IPv6 Flow ID"> <name>IPv6 Flow ID</name>
<artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA5 |U| Length = 4 | | Metadata Class = 0x0000 | Type = 0x08 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x0 | Reserved | IPv6 Flow ID | |CT=0x0 | Reserved | IPv6 Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</t> </figure>
<t> <figure anchor="flow-id-mplse-fig2">
<figure align="left" anchor="flow-id-mplse-fig2" title="MPLS entropy label"> <name>MPLS Entropy Label</name>
<artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class = 0x0000 | Type = TBA5 |U| Length = 4 | | Metadata Class = 0x0000 | Type = 0x08 |U| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CT=0x1 | Reserved | MPLS entropy label | |CT=0x1 | Reserved | MPLS entropy label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</t> </figure>
<t>
The fields are described as follows:
<list>
<t>Length: Indicates the length of the Flow ID in octets (see Sec
tion 2.5.1 of <xref target="RFC8300"/>). For example, IPv6 Flow Label in <xref t
arget="RFC8200"/> is 20-bit long. An entropy label in the MPLS network in <xref
target="RFC6790"/> is also 20-bit long. </t>
<t>Context Type (CT) is four bits-long field that defines the interpretat <t>The fields are described as follows:</t>
ion of the Flow ID field. Please see the IANA Considerations in <xref target="ia
na-tlv-flowid-type"/>. This document defines these CT values:
<list style="simbols">
<t>0x0 - 20 bits IPv6 Flow Label in <xref target="RFC8200
"/>. See <xref target='flow-id-ipv6-fig1'/>. </t>
<t>0x1 - 20 bits entropy label in the MPLS network in <xr
ef target="RFC6790"/>. See <xref target='flow-id-mplse-fig2'/>.</t>
</list>
Reserved bits in the context fields MUST be sent as zero
and ignored on receipt.
</t>
</list>
</t>
</section> <dl newline="false" spacing="normal">
<dt>Length:</dt>
<dd>Indicates the length of the Flow ID in octets (see <xref target
="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>). For example,
the IPv6 Flow Label in <xref target="RFC8200" format="default"/> is 20 bits long
. An entropy label in the MPLS network in <xref target="RFC6790" format="default
"/> is also 20 bits long. </dd>
<dt>Context Type (CT):</dt><dd><t>This 4-bit field that defines th
e interpretation of the Flow ID field. Please see the IANA considerations in <xr
ef target="iana-tlv-flowid-type" format="default"/>. This document defines these
CT values:</t>
<section anchor="src-dst-group-sec" title="Source and/or Destination Gro <dl newline="false" spacing="normal" indent="6">
ups"> <dt>0x0:</dt> <dd>20-bit IPv6 Flow Label in <xref target="RFC82
<t> 00" format="default"/>. See <xref target="flow-id-ipv6-fig1" format="default"/>.
</dd>
<dt>0x1:</dt> <dd>20-bit entropy label in the MPLS network in <
xref target="RFC6790" format="default"/>. See <xref target="flow-id-mplse-fig2"
format="default"/>.</dd>
</dl>
</dd>
<dt>Reserved:</dt><dd>These bits in the context fields <bcp14>MUST
</bcp14> be sent as zero and ignored on receipt.</dd>
</dl>
</section>
<section anchor="src-dst-group-sec" numbered="true" toc="default">
<name>Source and/or Destination Groups</name>
<t>
Intent-based systems can use this data to express the logical Intent-based systems can use this data to express the logical
grouping of source and/or destination objects. grouping of source and/or destination objects.
<xref target="OpenStack"/> and <xref target="OpenDaylight"/> provide exam ples of such a <xref target="OpenStack" format="default"/> and <xref target="OpenDayligh t" format="default"/> provide examples of such a
system. Each is expressed as a 32-bit opaque object. system. Each is expressed as a 32-bit opaque object.
<figure align="left" anchor="src-dst-group-fig" title="Source/Destinatio </t>
n Groups"> <figure anchor="src-dst-group-fig">
<artwork><![CDATA[ <name>Source/Destination Groups</name>
0 1 2 3 <artwork name="" type="" align="center" alt=""><![CDATA[
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 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
| Metadata Class = 0x0000 | Type = TBA6 |U| Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata Class = 0x0000 | Type = 0x09 |U| Length=8 |
| Source Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Group |
| Destination Group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</t> <t>
<t> If there is no group information specified for the Source Group or Destination G
If there is no group information specified for the source group or destination g roup field, the field <bcp14>MUST</bcp14> be sent as zero and ignored on receipt
roup field, the field MUST be sent as zero and ignored on receipt. .
</t> </t>
</section> </section>
<section anchor="policy-id-sec" numbered="true" toc="default">
<section anchor="policy-id-sec" title="Policy Identifier"> <name>Policy ID</name>
<t> <t>
Traffic handling policies are often referred to by a system-generated ide ntifier, which Traffic handling policies are often referred to by a system-generated ide ntifier, which
is then used by the devices to look up the policy's content is then used by the devices to look up the policy's content
locally. For example, this identifier could be an index to an locally. For example, this identifier could be an index to an
array, a lookup key, a database Id. The identifier allows array, a lookup key, or a database ID. The identifier allows
enforcement agents or services to look up the content of their enforcement agents or services to look up the content of their
part of the policy. part of the policy.
<figure align="left" anchor="policy-id-fig" title="Policy ID"> </t>
<artwork><![CDATA[ <figure anchor="policy-id-fig">
0 1 2 3 <name>Policy ID</name>
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 <artwork name="" type="" align="center" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
| Metadata Class = 0x0000 | Type = TBA7 |U| Length | 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Policy ID ~ | Metadata Class = 0x0000 | Type = 0x0A |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Policy ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</t> <t>The fields are described as follows:</t>
<t>
The fields are described as follows:
<list>
<t>Length: Indicates the length of the Policy ID in octets (see Section
2.5.1 of <xref target="RFC8300"/>).</t>
<t>Policy ID: Represents an opaque value of the Policy ID.</t>
</list>
</t>
<t>
This policy identifier is a general policy ID, essentially a key to allow Servic
e Functions to know which policies to apply to packets. Those policies generall
y will not have much to do with performance, but rather with what specific
treatment to apply. It may for example select a URL filter data set for a URL fi
lter, or select a video transcoding policy in a transcoding SF. The Performance
Policy Identifier in <xref target="RFC8979"/> is described there as having very
specific use, and for example says that fully controlled SFPs would not use it.
The Policy ID in this document is for cases not covered by <xref target="RFC8979
"/>.
</t>
</section> <dl newline="false" spacing="normal">
<dt>Length:</dt>
<dd>Indicates the length of the Policy ID in octets (see <xref ta
rget="RFC8300" section="2.5.1" sectionFormat="of" format="default"/>).</dd>
<dt>Policy ID:</dt>
<dd>Represents an opaque value of the Policy ID.</dd>
</dl>
</section> <t>
This Policy ID is a general Policy ID, essentially a key to allow Service Functi
ons (SFs) to know which policies to apply to packets. Those policies generally
will not have much to do with performance but rather with what specific
treatment to apply. It may, for example, select a URL filter data set for a URL
filter or select a video transcoding policy in a transcoding SF. The Performance
Policy ID in <xref target="RFC8979" format="default"/> is described there as ha
ving very specific use and, for example, says that fully controlled SFPs would n
ot use it. The Policy ID in this document is for cases not covered by <xref targ
et="RFC8979" format="default"/>.
<section anchor="security-sec" title="Security Considerations">
<t>A misbehaving node from within the SFC-enabled domain may alter the content o
f the Context Headers, which may lead to service disruption. Such an attack is n
ot unique to the Context Headers defined in this document. Measures discussed in
Section 8 of <xref target="RFC8300"/> describes the general security considerat
ions for protecting NSH. <xref target="I-D.ietf-sfc-nsh-integrity"/> specifies m
ethods of protecting the integrity of the NSH metadata. If the NSH includes the
MAC and Encrypted Metadata Context Header <xref target="RFC9145"/>, the authenti
cation of the packet MUST be verified before using any data. If the verification
fails, the receiver MUST stop processing the variable length context headers an
d notify an operator.
</t> </t>
</section>
<t>The security and privacy considerations for the 7 types of context header spe </section>
cified above are discussed below. Since NSH ignorant SFs will never see the NSH, <section anchor="security-sec" numbered="true" toc="default">
then even if they are malign, they cannot compromise security or privacy based <name>Security Considerations</name>
on the NSH or any of these context headers, although they could cause compromise <t>A misbehaving node from within the SFC-enabled domain may alter the con
based on the rest of the packet. To the extent that any of these headers is inc tent of the Context Headers, which may lead to service disruption. Such an attac
luded when it would be unneeded or have no effect, they provide a covert channel k is not unique to the Context Headers defined in this document. Measures discus
for the entity adding the context header to communicate a limited amount of arb sed in <xref target="RFC8300" section="8" sectionFormat="of" format="default"/>
itrary information to downstream entities within the SFC-enabled domain.</t> describes the general security considerations for protecting the NSH. <xref targ
et="RFC9145" format="default"/> specifies methods of protecting the integrity of
<section title="Forwarding Context"> the NSH metadata. If the NSH includes the Message Authentication Code (MAC) and
<t>All of the Forwarding Context variants specified in this document (those with Encrypted Metadata Context Header <xref target="RFC9145" format="default"/>, th
CT values between 0 and 4) merely repeat a field that is available in the packe e authentication of the packet <bcp14>MUST</bcp14> be verified before using any
t encapsulated by the NSH. These variants repeat that field in the NSH for conve data. If the verification fails, the receiver <bcp14>MUST</bcp14> stop processin
nience. Thus, there are no special security or privacy considerations in these c g the Variable-Length Context Headers and notify an operator.
ases. Any future new values of CT for the Forwarding Context must specify the se
curity and privacy considerations for those extensions.
</t> </t>
</section> <t>The security and privacy considerations for the 7 types of Context Head
<section title="Tenant Identifier"> ers specified above are discussed below. Since NSH-ignorant SFs will never see t
<t>The Tenant ID indicates the tenant to which traffic belongs and might be used he NSH, then even if they are malign, they cannot compromise security or privacy
to tie together and correlate packets for a tenant that some monitoring functio based on the NSH or any of these Context Headers; however, they could cause com
n could not otherwise group especially if other possible identifiers were being promise based on the rest of the packet. To the extent that any of these headers
randomized. As such, it may reduce security by facilitating traffic analysis but are included when they would be unneeded or have no effect, they provide a cove
only within the SFC-enabled domain where this context header is present in pack rt channel for the entity adding the Context Header to communicate a limited amo
ets. unt of arbitrary information to downstream entities within the SFC-enabled domai
n.</t>
<section numbered="true" toc="default">
<name>Forwarding Context</name>
<t>All of the Forwarding Context variants specified in this document (th
ose with CT values between 0 and 4) merely repeat a field that is available in t
he packet encapsulated by the NSH. These variants repeat that field in the NSH f
or convenience. Thus, there are no special security or privacy considerations in
these cases. Any future new values of CT for the Forwarding Context must specif
y the security and privacy considerations for those extensions.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Ingress Network Node Information"> <name>Tenant ID</name>
<t>The SFC-enabled domain manager normally operates the initial ingress / classi <t>The Tenant ID indicates the tenant to which traffic belongs and might
fier node and is thus potentially aware of the information provided by this cont be used to tie together and correlate packets for a tenant that some monitoring
ext header. Furthermore, in many cases the SPI that will be present in the NSH i function could not otherwise group, especially if other possible identifiers we
dentifies or closely constrains the ingress node. Also, in most cases, it is ant re being randomized. As such, it may reduce security by facilitating traffic ana
icipated that many entities will be sending packets into an SFC-enabled domain t lysis but only within the SFC-enabled domain where this Context Header is presen
hrough the same ingress node. Thus, under most circumstances, this context heade t in packets.
r is expected to weaken security and privacy to only a minor extent and only wit
hin the SFC-enabled domain.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Ingress Node Source Interface"> <name>Ingress Network Node Information</name>
<t>This context header is likely to be meaningless unless the Ingress Network No <t>The SFC-enabled domain manager normally operates the initial ingress/
de Information context header is also present. When that node information header classifier node and is thus potentially aware of the information provided by thi
is present, this source interface header provides a more fine-grained view of t s Context Header. Furthermore, in many cases, the SPI that will be present in th
he source by identifying not just the initial ingress / classifier node but also e NSH identifies or closely constrains the ingress node. Also, in most cases, it
the port of that node on which the data arrived. Thus, it is more likely to ide is anticipated that many entities will be sending packets into an SFC-enabled d
ntify a specific source entity or at least to more tightly constrain the set omain through the same ingress node. Thus, under most circumstances, this Contex
of possible source entities, than just the node information header. As a result, t Header is expected to weaken security and privacy to only a minor extent and o
inclusion of this context header with the node information context header is po nly within the SFC-enabled domain.
tentially a greater threat to security and privacy than the node information hea
der alone but this threat is still constrained to the SFC-enabled domain.</t>
</section>
<section title="Flow ID">
<t>The variations of this context header specified in this document simply repea
t fields already available in the packet and thus have no special security or pr
ivacy considerations. Any future new values of CT for the Flow ID must specify t
he security and privacy considerations for those extensions.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Source and/or Destination Groups"> <name>Ingress Node Source Interface</name>
<t>This context header provides additional information that might help identify <t>This Context Header is likely to be meaningless unless the Ingress Ne
the source and/or destination of packets. Depending on the granularity of the gr twork Node Information Context Header is also present. When that node informatio
oups, it could either (1) distinguish packets as part of flows from and/or to ob n header is present, this source interface header provides a more fine-grained v
jects where those flows could not otherwise be easily distinguished but appear t iew of the source by identifying not just the initial ingress/classifier node bu
o be part of one or fewer flows or (2) group packet flows that are from and/or t t also the port of that node on which the data arrived. Thus, it is more likely
o an object where those flows could not otherwise be easily grouped for analysis to identify a specific source entity or at least to more tightly constrain the s
or whatever. Thus, the presence of this context header with non-zero source and et of possible source entities than just the node information header. As a resul
/or destination groups can, within the SFC-enabled domain, erode security and pr t, inclusion of this Context Header with the node information Context Header is
ivacy to an extent that depends on the details of the grouping. potentially a greater threat to security and privacy than the node information h
eader alone, but this threat is still constrained to the SFC-enabled domain.</t>
</section>
<section numbered="true" toc="default">
<name>Flow ID</name>
<t>The variations of this Context Header specified in this document simp
ly repeat fields already available in the packet and thus have no special securi
ty or privacy considerations. Any future new values of CT for the Flow ID must s
pecify the security and privacy considerations for those extensions.
</t> </t>
</section> </section>
<section title="Policy Identifier"> <section numbered="true" toc="default">
<t> <name>Source and/or Destination Groups</name>
This context header carries an identifier that nodes in the SFC-enabled domain c <t>This Context Header provides additional information that might help i
an use to look up policy to potentially dentify the source and/or destination of packets. Depending on the granularity o
influence their actions with regard to the packet carrying this header. If there f the groups, it could either (1) distinguish packets as part of flows from and/
are no such action decisions, then the header should not be included. If are su or to objects where those flows could not otherwise be easily distinguished but
ch decisions, the information on which they are to be based needs to be included appear to be part of one or fewer flows or (2) group packet flows that are from
somewhere in the packet. There is no reason for inclusion in this context heade and/or to an object where those flows could not otherwise be easily grouped for
r to have any security or privacy considerations that would not apply to any oth analysis or another purpose.
er plaintext way of including such information. It may provide additional inform Thus, the presence of this Context Header with non-zero source and/or destinatio
ation to help identify a flow of data for analysis. n groups can, within the SFC-enabled domain, erode security and privacy to an ex
tent that depends on the details of the grouping.
</t> </t>
</section>
<section numbered="true" toc="default">
<name>Policy ID</name>
<t>
This Context Header carries an identifier that nodes in the SFC-enabled domain c
an use to look up policy to potentially
influence their actions with regard to the packet carrying this header. If there
are no such decisions regarding their actions, then the header should not be in
cluded. If there are such decisions, the information on which they are to be bas
ed needs to be included somewhere in the packet. There is no reason for inclusio
n in this Context Header to have any security or privacy considerations that wou
ld not apply to any other plaintext way of including such information. It may pr
ovide additional information to help identify a flow of data for analysis.
</t>
</section>
</section>
<section anchor="iana-tlv-class-reg-sec" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="iana-tlv-class-context-type" numbered="true" toc="default
">
<name>MD Type 2 Context Types</name>
<t>
IANA has assigned the following types (<xref target="type-values-tbl" for
mat="default"/>) from the "NSH IETF-Assigned Optional Variable-Length Metadata T
ypes" registry available at <xref target="IANA-NSH-MD2" format="default"/>.
</t>
<table anchor="type-values-tbl" align="center">
<name>Type Values</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="center">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x04</td>
<td align="center">Forwarding Context</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x05</td>
<td align="center">Tenant ID</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x06</td>
<td align="center">Ingress Network Node ID</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x07</td>
<td align="center">Ingress Network Interface</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x08</td>
<td align="center">Flow ID</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x09</td>
<td align="center">Source and/or Destination Groups</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x0A</td>
<td align="center">Policy ID</td>
<td align="left">RFC 9263</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana-fc-type" numbered="true" toc="default">
<name>Forwarding Context Types</name>
<t>IANA has created a new subregistry for "Forwarding Context Types" at
<xref target="IANA-NSH-MD2" format="default"/> as follows.
</t>
<t>The registration policy is IETF Review.</t>
<table anchor="Forwarding-CT-iana-tbl" align="center">
<name>Forwarding Context Types</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="center">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x0</td>
<td align="center">12-bit VLAN identifier</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x1</td>
<td align="center">24-bit double tagging identifiers</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x2</td>
<td align="center">20-bit MPLS VPN label</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x3</td>
<td align="center">24-bit virtual network identifier (VNI)</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x4</td>
<td align="center">32-bit Session ID</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x5-0xE</td>
<td align="center">Unassigned</td>
<td align="left"/>
</tr>
<tr>
<td align="left">0xF</td>
<td align="center">Reserved</td>
<td align="left">RFC 9263</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana-tlv-flowid-type" numbered="true" toc="default">
<name>Flow ID Context Types</name>
<t>IANA has created a new subregistry for "Flow ID Context Types" at <xr
ef target="IANA-NSH-MD2" format="default"/> as follows.
</t>
<t>The registration policy is IETF Review.</t>
<table anchor="flow-id-CT-iana-tbl" align="center">
<name>Flow ID Context Types</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="center">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x0</td>
<td align="center">20-bit IPv6 Flow Label</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x1</td>
<td align="center">20-bit entropy label in the MPLS network</td>
<td align="left">RFC 9263</td>
</tr>
<tr>
<td align="left">0x2-0xE</td>
<td align="center">Unassigned</td>
<td align="left"/>
</tr>
<tr>
<td align="left">0xF</td>
<td align="center">Reserved</td>
<td align="left">RFC 9263</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3931.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8300.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9145.
xml"/>
</section> <reference anchor="IEEE.802.1Q_2018" target="https://ieeexplore.ieee.org
/document/8403927">
<section title="Acknowledgments"> <front>
<t> <title>IEEE Standard for Local and Metropolitan Area Network -- Brid
The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von Hug ges and Bridged Networks</title>
o, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for providing invaluable
concepts and content for this document.
</t>
</section>
<section anchor="iana-tlv-class-reg-sec" title="IANA Considerations">
<section anchor="iana-tlv-class-context-type" title="MD Type 2 Context Types">
<t>
IANA is requested to assign the following types (<xref target="type-value
s-tbl"/>) from the "NSH IETF-Assigned Optional Variable-Length Metadata Types" r
egistry available at <xref target="IANA-NSH-MD2"/>.
</t>
<texttable anchor="type-values-tbl" title="Type Values">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>TBA1</c>
<c>Forwarding Context</c>
<c>This&nbsp;document</c>
<c>TBA2</c>
<c>Tenant Identifier</c>
<c>This&nbsp;document</c>
<c>TBA3</c>
<c>Ingress Network NodeID</c>
<c>This&nbsp;document</c>
<c>TBA4</c>
<c>Ingress Network Interface</c>
<c>This&nbsp;document</c>
<c>TBA5</c>
<c>Flow ID</c>
<c>This&nbsp;document</c>
<c>TBA6</c>
<c>Source and/or Destination Groups</c>
<c>This&nbsp;document</c>
<c>TBA7</c>
<c>Policy Identifier</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<!-- Add forwarding context Type sub-registry -->
<section anchor="iana-fc-type" title="Forwarding Context Types">
<t>IANA is requested to create a new sub-registry for "Forwarding
Context" context types at <xref target="IANA-NSH-MD2"/> as follows:
</t>
<t>The Registration Policy is IETF Review</t>
<texttable anchor="Forwarding-CT-iana-tbl" title="Forwarding Cont
ext Types">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Forwarding Context Header Types</tt
col>
<ttcol align="left">Reference</ttcol>
<c>0x0</c>
<c>12-bit VLAN identifier</c>
<c>This&nbsp;document</c>
<c>0x1</c>
<c>24-bit double tagging identifiers</c>
<c>This&nbsp;document</c>
<c>0x2</c>
<c>20-bit MPLS VPN label</c>
<c>This&nbsp;document</c>
<c>0x3</c>
<c>24-bit virtual network identifier (VNI)</c>
<c>This&nbsp;document</c>
<c>0x4</c>
<c>32-bit Session ID</c>
<c>This&nbsp;document</c>
<c>0x5-0xE</c>
<c>Unassigned</c>
<c></c>
<c>0xF</c>
<c>Reserved</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<!-- end of forwarding context Type sub-registry -->
<!-- Add flow id context Type sub-registry -->
<section anchor="iana-tlv-flowid-type" title="Flow ID Context Types">
<t>IANA is requested to create a new sub-registry for "Flow ID Co
ntext" context types at <xref target="IANA-NSH-MD2"/> as follows:
</t>
<t>The Registration Policy is IETF Review</t>
<texttable anchor="flow-id-CT-iana-tbl" title="Flow ID Context Ty
pes">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Flow ID Context Header Types</ttcol
>
<ttcol align="left">Reference</ttcol>
<c>0x0</c>
<c>20-bit IPv6 Flow Label</c>
<c>This&nbsp;document</c>
<c>0x1</c>
<c>20-bit entropy label in the MPLS network</c>
<c>This&nbsp;document</c>
<c>0x2-0xE</c>
<c>Unassigned</c>
<c></c>
<c>0xF</c>
<c>Reserved</c>
<c>This&nbsp;document</c>
</texttable>
</section>
<!-- end of flowid context Type sub-registry -->
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3931"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8300"?>
<?rfc include="reference.RFC.9145"?>
<?rfc include='reference.I-D.ietf-sfc-nsh-integrity'?>
<reference anchor="IEEE.802.1Q_2018" target="http://ieeexplore.ieee.org/
servlet/opac?punumber=8403925" >
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Brid
ges and Bridged Networks</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date month="July" year="2018"/> <date month="July" year="2018"/>
</front> </front>
</reference> </reference>
<reference anchor="IANA-NSH-MD2" target="https://www.iana.org/ass
ignments/nsh/nsh.xhtml#optional-variable-length-metadata-types"> <reference anchor="IANA-NSH-MD2" target="https://www.iana.org/assignment
<front> s/nsh">
<front>
<title> <title>
NSH IETF-Assigned Optional Variable-Length Metada ta Types Network Service Header (NSH) Parameters
</title> </title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> </front>
</front> </reference>
</reference>
<!--
<reference anchor="IANA-NSH-MD4">
<front>
<title>NSH IETF-Assigned Optional Variable-Length
Metadata Types</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
<format type="https://www.iana.org/assignments/nsh/nsh.xh
tml#optional-variable-length-metadata-types"/>
</reference>
</references> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8979.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2890.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7665.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8926.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3032.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.
xml"/>
<references title="Informative References"> <reference anchor="OpenDaylight-VTN" target="https://nexus.opendaylight.org/cont
<?rfc include="reference.RFC.8200"?> ent/sites/site/org.opendaylight.docs/master/userguide/manuals/userguide/bk-user-
<?rfc include="reference.RFC.6790"?> guide/content/_vtn.html">
<?rfc include="reference.RFC.8979"?> <front>
<?rfc include="reference.RFC.2890"?> <title>OpenDaylight VTN</title>
<?rfc include="reference.RFC.7665"?> <author>
<?rfc include="reference.RFC.8926"?> <organization>OpenDaylight</organization>
<?rfc include="reference.RFC.3032"?> </author>
<?rfc include="reference.RFC.4364"?> <date year="2021"/>
</front>
<reference anchor="OpenDaylight-VTN" target="https://nexus.openda </reference>
ylight.org/content/sites/site/org.opendaylight.docs/master/userguide/manuals/use
rguide/bk-user-guide/content/_vtn.html">
<front>
<title>OpenDaylight VTN</title>
<author>
<organization>OpenDaylight</organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="IANAifType" target="https://www.iana.org/assig <reference anchor="IANAifType" target="https://www.iana.org/assignments/
nments/ianaiftype-mib/ianaiftype-mib"> ianaiftype-mib/ianaiftype-mib">
<front> <front>
<title>IANAifType</title> <title>IANAifType-MIB DEFINITIONS</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
</reference> </reference>
<reference anchor="OpenStack" target="https://wiki.openstack.org/ <reference anchor="OpenStack" target="https://wiki.openstack.org/wiki/Gr
wiki/GroupBasedPolicy"> oupBasedPolicy">
<front> <front>
<title>Group Based Policy</title> <title>GroupBasedPolicy</title>
<author> <author>
<organization>OpenStack</organization> <organization>OpenStack</organization>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<!--<format type="https://wiki.openstack.org/wiki/GroupBa
sedPolicy"/>-->
</reference> </reference>
<reference anchor="OpenDaylight" target="https://docs.opendaylig <reference anchor="OpenDaylight" target="https://docs.opendaylight.org/e
ht.org/en/stable-fluorine/user-guide/group-based-policy-user-guide.html?highligh n/stable-fluorine/user-guide/group-based-policy-user-guide.html?highlight=group%
t=group%20policy#"> 20policy#">
<front> <front>
<title>Group Based Policy</title> <title>Group Based Policy User Guide</title>
<author> <author>
<organization>OpenDaylight</organization> <organization>OpenDaylight</organization>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<!--<format type="https://docs.opendaylight.org/en/stable
-fluorine/user-guide/group-based-policy-user-guide.html?highlight=group%20policy
#"/>-->
</reference> </reference>
</references>
</references> </references>
</back> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Paul Quinn"/>, <contac
t fullname="Behcet Sarikaya"/>, <contact fullname="Dirk von Hugo"/>, <contact fu
llname="Mohamed Boucadair"/>, <contact fullname="Gregory Mirsky"/>, and <contact
fullname="Joel Halpern"/> for providing invaluable concepts and content for thi
s document.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 66 change blocks. 
774 lines changed or deleted 828 lines changed or added

This html diff was produced by rfcdiff 1.48.