| < draft-ietf-sfc-nsh-tlv-14.txt | draft-ietf-sfc-nsh-tlv-15.txt > | |||
|---|---|---|---|---|
| SFC Yuehua. Wei, Ed. | Service Function Chaining Working Group Yuehua. Wei, Ed. | |||
| Internet-Draft ZTE Corporation | Internet-Draft ZTE Corporation | |||
| Intended status: Standards Track U. Elzur | Intended status: Standards Track U. Elzur | |||
| Expires: 1 October 2022 Intel | Expires: 22 October 2022 Intel | |||
| S. Majee | S. Majee | |||
| Individual contributor | Individual contributor | |||
| C. Pignataro | C. Pignataro | |||
| Cisco | Cisco | |||
| D. Eastlake | D. Eastlake | |||
| Futurewei Technologies | Futurewei Technologies | |||
| 30 March 2022 | 20 April 2022 | |||
| Network Service Header Metadata Type 2 Variable-Length Context Headers | Network Service Header (NSH) Metadata Type 2 Variable-Length Context | |||
| draft-ietf-sfc-nsh-tlv-14 | Headers | |||
| draft-ietf-sfc-nsh-tlv-15 | ||||
| Abstract | Abstract | |||
| Service Function Chaining (SFC) uses the Network Service Header (NSH) | Service Function Chaining (SFC) uses the Network Service Header (NSH) | |||
| (RFC 8300) to steer and provide context Metadata (MD) with each | (RFC 8300) to steer and provide context Metadata (MD) with each | |||
| packet. Such Metadata can be of various Types including MD Type 2 | packet. Such Metadata can be of various Types including MD Type 2 | |||
| variable length context headers. This document specifies several | consisting of variable length context headers. This document | |||
| such context headers that can be used within a service function path. | specifies several such context headers that can be used within a | |||
| service function path. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 1 October 2022. | This Internet-Draft will expire on 22 October 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 24 ¶ | skipping to change at page 2, line 24 ¶ | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
| 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
| 3. NSH MD Type 2 format . . . . . . . . . . . . . . . . . . . . 3 | 3. NSH MD Type 2 format . . . . . . . . . . . . . . . . . . . . 3 | |||
| 4. NSH MD Type 2 Context Headers . . . . . . . . . . . . . . . . 4 | 4. NSH MD Type 2 Context Headers . . . . . . . . . . . . . . . . 4 | |||
| 4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4 | 4.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 6 | 4.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.3. Ingress Network Node Information . . . . . . . . . . . . 6 | 4.3. Ingress Network Node Information . . . . . . . . . . . . 7 | |||
| 4.4. Ingress Network Source Interface . . . . . . . . . . . . 7 | 4.4. Ingress Network Source Interface . . . . . . . . . . . . 8 | |||
| 4.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 4.6. Source and/or Destination Groups . . . . . . . . . . . . 9 | 4.6. Source and/or Destination Groups . . . . . . . . . . . . 9 | |||
| 4.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 9 | 4.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 10 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
| 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.1. Forwarding Context . . . . . . . . . . . . . . . . . . . 11 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5.2. Tenant Identifier . . . . . . . . . . . . . . . . . . . . 12 | |||
| 7.1. MD Type 2 Context Types . . . . . . . . . . . . . . . . . 10 | 5.3. Ingress Network Node Information . . . . . . . . . . . . 12 | |||
| 7.2. Forwarding Context Types . . . . . . . . . . . . . . . . 11 | 5.4. Ingress Node Source Interface . . . . . . . . . . . . . . 12 | |||
| 7.3. Flow ID Context Types . . . . . . . . . . . . . . . . . . 12 | 5.5. Flow ID . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.6. Source and/or Destination Groups . . . . . . . . . . . . 13 | |||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 5.7. Policy Identifier . . . . . . . . . . . . . . . . . . . . 13 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 13 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 7.1. MD Type 2 Context Types . . . . . . . . . . . . . . . . . 13 | ||||
| 7.2. Forwarding Context Types . . . . . . . . . . . . . . . . 14 | ||||
| 7.3. Flow ID Context Types . . . . . . . . . . . . . . . . . . 15 | ||||
| 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
| 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 | ||||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 16 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
| 1. Introduction | 1. Introduction | |||
| The Network Service Header (NSH) [RFC8300] is the Service Function | The Network Service Header (NSH) [RFC8300] is the Service Function | |||
| Chaining (SFC) encapsulation that supports the SFC architecture | Chaining (SFC) encapsulation that supports the SFC architecture | |||
| [RFC7665]. As such, the NSH provides following key elements: | [RFC7665]. As such, the NSH provides following key elements: | |||
| 1. Service Function Path (SFP) identification. | 1. Service Function Path (SFP) identification. | |||
| 2. Indication of location within a Service Function Path. | 2. Indication of location within a Service Function Path. | |||
| 3. Optional, per-packet metadata (fixed-length or variable-length). | 3. Optional, per-packet metadata (fixed-length or variable-length). | |||
| [RFC8300] further defines two metadata formats (MD Types): 1 and 2. | [RFC8300] further defines two metadata formats (MD Types): 1 and 2. | |||
| MD Type 1 defines the fixed-length, 16-octet long metadata, whereas | MD Type 1 defines the fixed-length, 16-octet long metadata, whereas | |||
| MD Type 2 defines a variable-length context format for metadata. | MD Type 2 defines a variable-length context format for metadata. | |||
| This document defines several common metadata context headers for use | This document defines several common metadata context headers for use | |||
| with NSH MD Type 2. These supplement the Subscriber Identity and | within NSH MD Type 2. These supplement the Subscriber Identity and | |||
| Performance Policy MD Type 2 metadata context headers specified in | Performance Policy MD Type 2 metadata context headers specified in | |||
| [RFC8979]. | [RFC8979]. | |||
| 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 | metadata, or other SFP functions. Those topics are described in | |||
| [RFC8300]. | [RFC8300]. | |||
| 2. Conventions used in this document | 2. Conventions used in this document | |||
| 2.1. Terminology | 2.1. Terminology | |||
| skipping to change at page 4, line 19 ¶ | skipping to change at page 4, line 26 ¶ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Variable-Length Metadata | | | Variable-Length Metadata | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 2: NSH Variable-Length Context Headers | Figure 2: NSH Variable-Length Context Headers | |||
| 4. NSH MD Type 2 Context Headers | 4. NSH MD Type 2 Context Headers | |||
| [RFC8300] specifies Metadata Class 0x0000 as IETF Base NSH MD Class. | [RFC8300] specifies Metadata Class 0x0000 as IETF Base NSH MD Class. | |||
| In this document, metadata types are defined for the IETF Base NSH MD | In this document, metadata types are defined for the IETF Base NSH MD | |||
| Class. | Class. The Context Headers specified in the subsections below are as | |||
| follows: | ||||
| 1. Forwarding Context | ||||
| 2. Tenant Identifier | ||||
| 3. Ingress Network Node Information | ||||
| 4. Ingress Node Source Interface | ||||
| 5. Flow ID | ||||
| 6. Source and/or Destination Groups | ||||
| 7. Policy Identifier | ||||
| 4.1. Forwarding Context | 4.1. Forwarding Context | |||
| 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. Forwarding context can take | |||
| several forms depending on the network environment. For example, | several forms depending on the network environment. For example, | |||
| VXLAN/VXLAN-GPE VNID, VRF identification, or VLAN. | VXLAN/VXLAN-GPE VNID, VRF identification, or VLAN. | |||
| 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 = TBA1 |U| Length = 4 | | | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x0 | Reserved | VLAN ID | | |CT=0x0 | Reserved | VLAN ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 3: Forwarding Context - 1(VLAN) | Figure 3: VLAN Forwarding Context | |||
| 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 = TBA1 |U| Length = 4 | | | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x1 |Resv | Service VLAN ID | Customer VLAN ID | | |CT=0x1 |Resv | Service VLAN ID | Customer VLAN ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 4: Forwarding Context - 2(QinQ) | Figure 4: QinQ Forwarding Context | |||
| 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 = TBA1 |U| Length = 4 | | | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x2 | Reserved | MPLS VPN Label | | |CT=0x2 | Reserved | MPLS VPN Label | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 5: Forwarding Context - 3(MPLS VPN) | Figure 5: MPLS VPN Forwarding Context | |||
| 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 = TBA1 |U| Length = 4 | | | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 4 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x3 | Resv | Virtual Network Identifier | | |CT=0x3 | Resv | Virtual Network Identifier | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 6: Forwarding Context - 4(VNI) | Figure 6: VNI Forwarding Context | |||
| 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 = TBA1 |U| Length = 8 | | | Metadata Class = 0x0000 | Type = TBA1 |U| Length = 8 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x4 | Reserved | | |CT=0x4 | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Session ID | | | Session ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 7: Forwarding Context - 5(Session ID) | Figure 7: Session ID Forwarding Context | |||
| where: | where: | |||
| Context Type (CT) is four bits-long field that defines the length | Context Type (CT) is four bits-long field that defines the | |||
| and the interpretation of the Forwarding Context field. Please | interpretation of the Forwarding Context field. Please see the | |||
| see the IANA Considerations in Section 7.2. This document defines | IANA Considerations in Section 7.2. This document defines these | |||
| these CT values: | CT values: | |||
| - 0x0 - 12 bits VLAN identifier [IEEE.802.1Q_2018]. See | - 0x0 - 12 bits VLAN identifier [IEEE.802.1Q_2018]. See | |||
| Figure 3. | Figure 3. | |||
| - 0x1 - 24 bits double tagging identifiers. A service VLAN tag | - 0x1 - 24 bits double tagging identifiers. A service VLAN tag | |||
| followed by a customer VLAN tag [IEEE.802.1Q_2018]. The two | followed by a customer VLAN tag [IEEE.802.1Q_2018]. The two | |||
| VLAN IDs are concatenated and appear in the same order that | VLAN IDs are concatenated and appear in the same order that | |||
| they appeared in the payload. See Figure 4. | they appeared in the payload. See Figure 4. | |||
| - 0x2 - 20 bits MPLS VPN label([RFC3032])([RFC4364]). See | - 0x2 - 20 bits MPLS VPN label([RFC3032])([RFC4364]). See | |||
| Figure 5. | Figure 5. | |||
| - 0x3 - 24 bits virtual network identifier (VNI)[RFC8926]. See | - 0x3 - 24 bits virtual network identifier (VNI)[RFC8926]. See | |||
| Figure 6. | Figure 6. | |||
| - 0x4 - 32 bits Session ID ([RFC3931]). This is called Key in | - 0x4 - 32 bits Session ID ([RFC3931]). This is called Key in | |||
| GRE [RFC2890]. See Figure 7. | GRE [RFC2890]. See Figure 7. | |||
| Reserved bits in the context fields MUST be sent as zero and | Reserved (Resv) bits in the context fields MUST be sent as zero | |||
| ignored on receipt. | and ignored on receipt. | |||
| 4.2. Tenant Identifier | 4.2. Tenant Identifier | |||
| Tenant identification is often used for segregation within a multi- | Tenant identification is often used for segregation within a multi- | |||
| tenant environment. Orchestration system-generated tenant IDs are an | tenant environment. Orchestration system-generated tenant IDs are an | |||
| example of such data. This context header carries the value of the | example of such data. This context header carries the value of the | |||
| Tenant identifier. [OpenDaylight-VTN] Virtual Tenant Network (VTN) | Tenant identifier. [OpenDaylight-VTN] Virtual Tenant Network (VTN) | |||
| is an application that provides multi-tenant virtual network on an | is an application that provides multi-tenant virtual network on an | |||
| SDN controller. | SDN controller. | |||
| 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 = TBA2 |U| Length = var| | | Metadata Class = 0x0000 | Type = TBA2 |U| Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ Tenant ID ~ | ~ Tenant ID ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 8: Tenant Identifier List | Figure 8: Tenant Identifier List | |||
| The fields are described as follows: | The fields are described as follows: | |||
| Length: Indicates the length of the Tenant ID in octets (see | Length: Indicates the length of the Tenant ID in octets (see | |||
| Section 2.5.1 of [RFC8300]). | Section 2.5.1 of [RFC8300]). | |||
| Tenant ID: Represents an opaque value pointing to Orchestration | Tenant ID: Represents an opaque value pointing to Orchestration | |||
| system-generated tenant identifier. The structure and semantics | system-generated tenant identifier. The structure and semantics | |||
| of this field are specific to the operator's deployment across its | of this field are specific to the operator's deployment across its | |||
| operational domain, and are specified and assigned by an | operational domain, and are specified and assigned by an | |||
| orchestration function. The specifics of that orchestration-based | orchestration function. The specifics of that orchestration-based | |||
| assignment are outside the scope of this document. | assignment are outside the scope of this document. | |||
| 4.3. Ingress Network Node Information | 4.3. Ingress Network Node Information | |||
| This context header carries a Node ID of the ingress network node. | This context header carries a Node ID of the network node at which | |||
| the packet entered the SFC-enabled domain. This node will | ||||
| necessarily be a Classifier [RFC7665]. In cases where the SPI | ||||
| identifies the ingress node, this context header is superfluous. | ||||
| 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 = TBA3 |U| Length = var| | | Metadata Class = 0x0000 | Type = TBA3 |U| Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ Node ID ~ | ~ Node ID ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 9: Ingress Network Node ID | Figure 9: Ingress Network Node ID | |||
| The fields are described as follows: | The fields are described as follows: | |||
| Length: Indicates the length of the Node ID in octets (see | Length: Indicates the length of the Node ID in octets (see | |||
| Section 2.5.1 of [RFC8300]). | Section 2.5.1 of [RFC8300]). | |||
| skipping to change at page 7, line 35 ¶ | skipping to change at page 8, line 20 ¶ | |||
| 4.4. Ingress Network Source Interface | 4.4. Ingress Network Source Interface | |||
| This context identifies the ingress interface of the ingress network | This context identifies the ingress interface of the ingress network | |||
| node. The l2vlan (135), l3ipvlan (136), ipForward (142), mpls (166) | node. The l2vlan (135), l3ipvlan (136), ipForward (142), mpls (166) | |||
| in [IANAifType] are examples of source interfaces. | in [IANAifType] are examples of source interfaces. | |||
| 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 = TBA4 |U| Length = var| | | Metadata Class = 0x0000 | Type = TBA4 |U| Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ Source Interface ~ | ~ Source Interface ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 10: Ingress Network Source Interface | Figure 10: Ingress Network Source Interface | |||
| The fields are described as follows: | The fields are described as follows: | |||
| Length: Indicates the length of the Source Interface in octets | Length: Indicates the length of the Source Interface in octets | |||
| (see Section 2.5.1 of [RFC8300]). | (see Section 2.5.1 of [RFC8300]). | |||
| skipping to change at page 8, line 12 ¶ | skipping to change at page 8, line 42 ¶ | |||
| Source Interface: Represents an opaque value of identifier of the | Source Interface: Represents an opaque value of identifier of the | |||
| ingress interface of the ingress network node. | ingress interface of the ingress network node. | |||
| 4.5. Flow ID | 4.5. Flow ID | |||
| Flow ID provides a field in the NSH MD Type 2 to label packets | Flow ID provides a field in the NSH MD Type 2 to label packets | |||
| belonging to the same flow. For example, [RFC8200] defined IPv6 Flow | belonging to the same flow. For example, [RFC8200] defined IPv6 Flow | |||
| Label as Flow ID, [RFC6790] defined an entropy label which is | Label as Flow ID, [RFC6790] defined an entropy label which is | |||
| generated based on flow information in the MPLS network is another | generated based on flow information in the MPLS network is another | |||
| example of Flow ID. Absence of this field, or a value of zero | example of Flow ID. Absence of this field, or a value of zero | |||
| denotes that packets have not been labeled. | denotes that packets have not been labeled with a Flow ID. | |||
| 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 = TBA5 |U| Length = 4 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x0 | Reserved | IPv6 Flow ID | | |CT=0x0 | Reserved | IPv6 Flow ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 11: IPv6 Flow ID | Figure 11: IPv6 Flow ID | |||
| 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 = TBA5 |U| Length = 4 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |CT=0x1 | Reserved | MPLS entropy label | | |CT=0x1 | Reserved | MPLS entropy label | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 12: MPLS entropy label | Figure 12: MPLS entropy label | |||
| The fields are described as follows: | The fields are described as follows: | |||
| Length: Indicates the length of the Flow ID in octets (see | Length: Indicates the length of the Flow ID in octets (see | |||
| Section 2.5.1 of [RFC8300]). For example, IPv6 Flow Label in | Section 2.5.1 of [RFC8300]). For example, IPv6 Flow Label in | |||
| [RFC8200] is 20-bit long. An entropy label in the MPLS network in | [RFC8200] is 20-bit long. An entropy label in the MPLS network in | |||
| [RFC6790] is also 20-bit long. | [RFC6790] is also 20-bit long. | |||
| Context Type (CT) is four bits-long field that defines the length | Context Type (CT) is four bits-long field that defines the | |||
| and the interpretation of the Flow ID field. Please see the IANA | interpretation of the Flow ID field. Please see the IANA | |||
| Considerations in Section 7.3. This document defines these CT | Considerations in Section 7.3. This document defines these CT | |||
| values: | values: | |||
| - 0x0 - 20 bits IPv6 Flow Label in [RFC8200]. See Figure 11. | - 0x0 - 20 bits IPv6 Flow Label in [RFC8200]. See Figure 11. | |||
| - 0x1 - 20 bits entropy label in the MPLS network in [RFC6790]. | - 0x1 - 20 bits entropy label in the MPLS network in [RFC6790]. | |||
| See Figure 12. | See Figure 12. | |||
| Reserved bits in the context fields MUST be sent as zero and | Reserved bits in the context fields MUST be sent as zero and | |||
| ignored on receipt. | ignored on receipt. | |||
| skipping to change at page 9, line 22 ¶ | skipping to change at page 10, line 12 ¶ | |||
| [OpenDaylight] provide examples of such a system. Each is expressed | [OpenDaylight] provide examples of such a system. Each is expressed | |||
| as a 32-bit opaque object. | as a 32-bit opaque object. | |||
| 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 = TBA6 |U| Length=8 | | | Metadata Class = 0x0000 | Type = TBA6 |U| Length=8 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Source Group | | | Source Group | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Dest Group | | | Destination Group | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 13: Source/Dest Groups | Figure 13: Source/Destination Groups | |||
| If there is no group information specified for the source group or | If there is no group information specified for the source group or | |||
| dest group field, the field MUST be sent as zero and ignored on | destination group field, the field MUST be sent as zero and ignored | |||
| receipt. | on receipt. | |||
| 4.7. Policy Identifier | 4.7. Policy Identifier | |||
| Traffic handling policies are often referred to by a system-generated | Traffic handling policies are often referred to by a system-generated | |||
| identifier, which is then used by the devices to look up the policy's | identifier, which is then used by the devices to look up the policy's | |||
| content locally. For example, this identifier could be an index to | content locally. For example, this identifier could be an index to | |||
| an array, a lookup key, a database Id. The identifier allows | an array, a lookup key, a database Id. The identifier allows | |||
| enforcement agents or services to look up the content of their part | enforcement agents or services to look up the content of their part | |||
| of the policy. | of the policy. | |||
| 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 = TBA7 |U| Length=var | | | Metadata Class = 0x0000 | Type = TBA7 |U| Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ~ Policy ID ~ | ~ Policy ID ~ | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 14: Policy ID | Figure 14: Policy ID | |||
| The fields are described as follows: | The fields are described as follows: | |||
| Length: Indicates the length of the Policy ID in octets (see | Length: Indicates the length of the Policy ID in octets (see | |||
| Section 2.5.1 of [RFC8300]). | Section 2.5.1 of [RFC8300]). | |||
| skipping to change at page 10, line 29 ¶ | skipping to change at page 11, line 18 ¶ | |||
| [RFC8979]. | [RFC8979]. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| A misbehaving node from within the SFC-enabled domain may alter the | A misbehaving node from within the SFC-enabled domain may alter the | |||
| content of the Context Headers, which may lead to service disruption. | content of the Context Headers, which may lead to service disruption. | |||
| Such an attack is not unique to the Context Headers defined in this | Such an attack is not unique to the Context Headers defined in this | |||
| document. Measures discussed in Section 8 of [RFC8300] describes the | document. Measures discussed in Section 8 of [RFC8300] describes the | |||
| general security considerations for protecting NSH. | general security considerations for protecting NSH. | |||
| [I-D.ietf-sfc-nsh-integrity] specifies methods of protecting the | [I-D.ietf-sfc-nsh-integrity] specifies methods of protecting the | |||
| integrity of the NSH metadata. If the NSH includes the MAC Context | integrity of the NSH metadata. If the NSH includes the MAC and | |||
| Header, the authentication of the packet MUST be verified before | Encrypted Metadata Context Header [RFC9145], the authentication of | |||
| using any data. If the verification fails, the receiver MUST stop | the packet MUST be verified before using any data. If the | |||
| processing the variable length context headers and notify an | verification fails, the receiver MUST stop processing the variable | |||
| operator. | length context headers and notify an operator. | |||
| The security and privacy considerations for the 7 types of context | ||||
| header specified above are discussed below. Since NSH ignorant SFs | ||||
| will never see the NSH, then even if they are malign, they cannot | ||||
| compromise security or privacy based on the NSH or any of these | ||||
| context headers, although they could cause compromise based on the | ||||
| rest of the packet. To the extent that any of these headers is | ||||
| included when it would be unneeded or have no effect, they provide a | ||||
| covert channel for the entity adding the context header to | ||||
| communicate a limited amount of arbitrary information to downstream | ||||
| entities within the SFC-enabled domain. | ||||
| 5.1. Forwarding Context | ||||
| All of the Forwarding Context variants specified in this document | ||||
| (those with CT values between 0 and 4) merely repeat a field that is | ||||
| available in the packet encapsulated by the NSH. These variants | ||||
| repeat that field in the NSH for convenience. Thus, there are no | ||||
| special security or privacy considerations in these cases. Any | ||||
| future new values of CT for the Forwarding Context must specify the | ||||
| security and privacy considerations for those extensions. | ||||
| 5.2. Tenant Identifier | ||||
| The Tenant ID indicates the tenant to which traffic belongs and might | ||||
| be used to tie together and correlate packets for a tenant that some | ||||
| monitoring function could not otherwise group especially if other | ||||
| possible identifiers were being randomized. As such, it may reduce | ||||
| security by facilitating traffic analysis but only within the SFC- | ||||
| enabled domain where this context header is present in packets. | ||||
| 5.3. Ingress Network Node Information | ||||
| The SFC-enabled domain manager normally operates the initial ingress | ||||
| / classifier node and is thus potentially aware of the information | ||||
| provided by this context header. Furthermore, in many cases the SPI | ||||
| that will be present in the NSH identifies or closely constrains the | ||||
| ingress node. Also, in most cases, it is anticipated that many | ||||
| entities will be sending packets into an SFC-enabled domain through | ||||
| the same ingress node. Thus, under most circumstances, this context | ||||
| header is expected to weaken security and privacy to only a minor | ||||
| extent and only within the SFC-enabled domain. | ||||
| 5.4. Ingress Node Source Interface | ||||
| This context header is likely to be meaningless unless the Ingress | ||||
| Network Node Information context header is also present. When that | ||||
| node information header is present, this source interface header | ||||
| provides a more fine-grained view of the source by identifying not | ||||
| just the initial ingress / classifier node but also the port of that | ||||
| node on which the data arrived. Thus, it is more likely to identify | ||||
| a specific source entity or at least to more tightly constrain the | ||||
| set of possible source entities, than just the node information | ||||
| header. As a result, inclusion of this context header with the node | ||||
| information context header is potentially a greater threat to | ||||
| security and privacy than the node information header alone but this | ||||
| threat is still constrained to the SFC-enabled domain. | ||||
| 5.5. Flow ID | ||||
| The variations of this context header specified in this document | ||||
| simply repeat fields already available in the packet and thus have no | ||||
| special security or privacy considerations. Any future new values of | ||||
| CT for the Flow ID must specify the security and privacy | ||||
| considerations for those extensions. | ||||
| 5.6. Source and/or Destination Groups | ||||
| This context header provides additional information that might help | ||||
| identify the source and/or destination of packets. Depending on the | ||||
| granularity of the groups, it could either (1) distinguish packets as | ||||
| part of flows from and/or to objects where those flows could not | ||||
| otherwise be easily distinguished but appear to be part of one or | ||||
| fewer flows or (2) group packet flows that are from and/or to an | ||||
| object where those flows could not otherwise be easily grouped for | ||||
| analysis or whatever. Thus, the presence of this context header with | ||||
| non-zero source and/or destination groups can, within the SFC-enabled | ||||
| domain, erode security and privacy to an extent that depends on the | ||||
| details of the grouping. | ||||
| 5.7. Policy Identifier | ||||
| This context header carries an identifier that nodes in the SFC- | ||||
| enabled domain can use to look up policy to potentially influence | ||||
| their actions with regard to the packet carrying this header. If | ||||
| there are no such action decisions, then the header should not be | ||||
| included. If are such decisions, the information on which they are | ||||
| to be based needs to be included somewhere in the packet. There is | ||||
| no reason for inclusion in this context header to have any security | ||||
| or privacy considerations that would not apply to any other plaintext | ||||
| way of including such information. It may provide additional | ||||
| information to help identify a flow of data for analysis. | ||||
| 6. Acknowledgments | 6. Acknowledgments | |||
| The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von | The authors would like to thank Paul Quinn, Behcet Sarikaya, Dirk von | |||
| Hugo, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for | Hugo, Mohamed Boucadair, Gregory Mirsky, and Joel Halpern for | |||
| providing invaluable concepts and content for this document. | providing invaluable concepts and content for this document. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| 7.1. MD Type 2 Context Types | 7.1. MD Type 2 Context Types | |||
| IANA is requested to assign the following types (Table 1) from the | IANA is requested to assign the following types (Table 1) from the | |||
| "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry | "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry | |||
| available at [IANA-NSH-MD2]. | available at [IANA-NSH-MD2]. | |||
| +=======+==================================+===============+ | +=======+==================================+===============+ | |||
| | Value | Description | Reference | | | Value | Description | Reference | | |||
| +=======+==================================+===============+ | +=======+==================================+===============+ | |||
| | TBA1 | Forwarding Context | This document | | | TBA1 | Forwarding Context | This document | | |||
| +-------+----------------------------------+---------------+ | +-------+----------------------------------+---------------+ | |||
| | TBA2 | Tenant Identifier | This document | | | TBA2 | Tenant Identifier | This document | | |||
| +-------+----------------------------------+---------------+ | +-------+----------------------------------+---------------+ | |||
| | TBA3 | Ingress Network NodeID | This document | | | TBA3 | Ingress Network NodeID | This document | | |||
| skipping to change at page 13, line 24 ¶ | skipping to change at page 16, line 24 ¶ | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., | |||
| "Network Service Header (NSH)", RFC 8300, | "Network Service Header (NSH)", RFC 8300, | |||
| DOI 10.17487/RFC8300, January 2018, | DOI 10.17487/RFC8300, January 2018, | |||
| <https://www.rfc-editor.org/info/rfc8300>. | <https://www.rfc-editor.org/info/rfc8300>. | |||
| [RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity | ||||
| Protection for the Network Service Header (NSH) and | ||||
| Encryption of Sensitive Context Headers", RFC 9145, | ||||
| DOI 10.17487/RFC9145, December 2021, | ||||
| <https://www.rfc-editor.org/info/rfc9145>. | ||||
| 8.2. Informative References | 8.2. Informative References | |||
| [IANAifType] | [IANAifType] | |||
| IANA, "IANAifType", 2021, | IANA, "IANAifType", 2021, | |||
| <https://www.iana.org/assignments/ianaiftype-mib/ | <https://www.iana.org/assignments/ianaiftype-mib/ | |||
| ianaiftype-mib>. | ianaiftype-mib>. | |||
| [OpenDaylight] | [OpenDaylight] | |||
| OpenDaylight, "Group Based Policy", 2021, | OpenDaylight, "Group Based Policy", 2021, | |||
| <https://docs.opendaylight.org/en/stable-fluorine/user- | <https://docs.opendaylight.org/en/stable-fluorine/user- | |||
| skipping to change at page 14, line 49 ¶ | skipping to change at page 18, line 4 ¶ | |||
| Authors' Addresses | Authors' Addresses | |||
| Yuehua Wei (editor) | Yuehua Wei (editor) | |||
| ZTE Corporation | ZTE Corporation | |||
| No.50, Software Avenue | No.50, Software Avenue | |||
| Nanjing | Nanjing | |||
| 210012 | 210012 | |||
| China | China | |||
| Email: wei.yuehua@zte.com.cn | Email: wei.yuehua@zte.com.cn | |||
| Uri Elzur | Uri Elzur | |||
| Intel | Intel | |||
| Email: uri.elzur@intel.com | Email: uri.elzur@intel.com | |||
| Sumandra Majee | Sumandra Majee | |||
| Individual contributor | Individual contributor | |||
| Email: Sum.majee@gmail.com | Email: Sum.majee@gmail.com | |||
| Carlos Pignataro | Carlos Pignataro | |||
| Cisco | Cisco | |||
| Email: cpignata@cisco.com | Email: cpignata@cisco.com | |||
| Donald E. Eastlake | Donald E. Eastlake | |||
| Futurewei Technologies | Futurewei Technologies | |||
| 2386 Panoramic Circle | ||||
| Apopka, FL 32703 | ||||
| United States of America | ||||
| Email: d3e3e3@gmail.com | Email: d3e3e3@gmail.com | |||
| End of changes. 33 change blocks. | ||||
| 54 lines changed or deleted | 180 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||