CARVIEW |
Select Language
HTTP/2 200
date: Wed, 08 Oct 2025 21:54:41 GMT
content-type: application/rfc+xml; charset=utf-8
content-length: 3666
cf-ray: 98b8e0c9b821cf00-BLR
last-modified: Sat, 12 Aug 2023 01:22:50 GMT
etag: "30bf-602afaaf3a058-gzip"
accept-ranges: bytes
vary: Accept-Encoding
content-encoding: gzip
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
cf-cache-status: DYNAMIC
set-cookie: __cf_bm=uNaYmUiVs7QnNC6F174M.U.n4wVurr9PE0hBZAAWrVA-1759960481-1.0.1.1-oBqpisBYZ3Z0vSuXuZPn5431t160Bu5Jrcty2SnSRo8y1FQVe7XH27Losa7cn7BbmXKWcjzUZ0mOtGZyNAax.SSG0GeBOtOwbStRD4cMJeU; path=/; expires=Wed, 08-Oct-25 22:24:41 GMT; domain=.rfc-editor.org; HttpOnly; Secure; SameSite=None
server: cloudflare
alt-svc: h3=":443"; ma=86400
]>
Operations, Administration, and Maintenance
(OAM) Packet and Behavior in the Network Service Header (NSH)
Orange
Rennes
France
mohamed.boucadair@orange.com
rtg
sfc
Diagnostic
Troubelshooting
Service Function Chaining
Automation
SDN
Programmable Networks
Service Differentiation
This document clarifies an ambiguity in the Network Service Header
(NSH) specification related to the handling of O bit. In particular,
this document clarifies the meaning of "OAM packet".
This document updates RFC 8300.
Introduction
This document clarifies an ambiguity related to the definition of
the Operations, Administration, and Maintenance (OAM) packet discussed in
.
Processing of the O bit in the Network Service Header (NSH) must
follow the updated behavior specified in .
Terminology
The key words "MUST ", "MUST NOT ",
"REQUIRED ", "SHALL ", "SHALL
NOT ", "SHOULD ", "SHOULD NOT ",
"RECOMMENDED ", "NOT RECOMMENDED ",
"MAY ", and "OPTIONAL " in this document
are to be interpreted as described in BCP 14 when, and only when, they
appear in all capitals, as shown here.
This document makes use of the terms defined in and .
The document defines the following terms:
An Update to RFC 8300
This document updates as follows:
OLD:
NEW:
IANA Considerations
This document has no IANA actions.
Security Considerations
Data plane SFC-related security considerations, including privacy,
are discussed in
and . Additional
security considerations related to SFC OAM are discussed in .
Any data included in an NSH OAM packet SHOULD be
integrity protected .
References
Normative References
Informative References
Acknowledgments
Thanks to , , , , ,
, and for the comments.
Thanks to for the art directorate
review and for the security
directorate review.
Thanks to and for their IESG reviews.
35000
- Service Function Chaining (SFC) data plane element:
- refers to the SFC-aware Service Function (SF), Service Function
Forwarder (SFF), SFC Proxy, or Classifier as defined in the SFC data
plane architecture
and further refined in . - OAM control element:
- an NSH-aware element that is capable of generating NSH OAM packets. An SFC data plane element may behave as an OAM control element.
- SFC OAM data:
- refers to an OAM request (e.g., Connectivity Verification and
Continuity Checks
), any data that influences how to execute a companion OAM request (e.g., identity of a terminating SF), the output data of an OAM request, and any combination thereof. - User data:
- refers to user packets cited in
.
- O bit:
Setting this bit indicates an OAM packet (see ). The actual format and processing of SFC OAM packets is outside the scope of this specification (for example, see [SFC-OAM-FRAMEWORK] for one approach). The O bit MUST be set for OAM packets andMUST NOT be set for non-OAM packets. The O bitMUST NOT be modified along the SFP.SF/SFF/SFC Proxy/Classifier implementations that do not support SFC OAM procedures SHOULD discard packets with O bit set, butMAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain. Forwarding OAM packets unmodified by SFC elements that do not support SFC OAM procedures may be acceptable for a subset of OAM functions, but it can result in unexpected outcomes for others; thus, it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior. The configurable parameterMUST be disabled by default.
- O bit:
Setting this bit indicates an NSH OAM packet. Such a packet is any NSH-encapsulated packet that exclusively includes SFC OAM data. SFC OAM data can be included in the Fixed-Length Context Header, optional Context Headers, and/or the inner packet. The O bit is typically set by an OAM controller or a final destination of an NSH OAM packet that triggers a response (e.g., a specific SFC-aware SF or the last SFF of an SFP). The O bit MUST be set for NSH OAM packets andMUST NOT be set for non-OAM packets. The O bitMUST NOT be modified along the SFP.NSH-encapsulated packets that include user data are not considered NSH OAM packets even if some SFC OAM data (e.g., record route) is also supplied in the packet. When SFC OAM data is included in the inner packet, the Next Protocol field is set to reflect the structure of that inner OAM packet. The setting and processing of the O bit neither assumes nor expects detailed analysis of the content of any inner IP packet carried by the NSH. In order to prevent non-deterministic behaviors, SFC data plane elements MAY support a configuration parameter to filter valid Next Protocol values in NSH OAM packets. Absent explicit configuration, SFFs, SFC-aware SFs, and SFC ProxiesSHOULD discard any NSH packets with the O bit set and Next Protocol set to something that is not itself an OAM protocol. This includes discarding the packet when the O bit is set and the Next Protocol is set to 0x01 (IPv4), 0x02 (IPv6), 0x03 (MPLS), or 0x05 (Ethernet).An NSH OAM packet MAY include optional Context Headers (e.g., a subscriber identifieror a flow identifier ) that are used to influence the processing of the packet by SFC data plane elements. An NSH OAM packet MAY include SFC OAM data in both Context Headers and the inner packet. The processing of the SFC OAM data (including the order)SHOULD be specified in the relevant OAM or Context Header specification.SFC-aware implementations of SF, SFF, SFC Proxy, and Classifier that do not support SFC OAM procedures SHOULD discard packets with the O bit set butMAY support a configurable parameter to enable forwarding received NSH OAM packets unmodified to the next element in the chain. Forwarding NSH OAM packets unmodified by SFC data plane elements that do not support SFC OAM procedures may be acceptable for a subset of OAM functions, but it can result in unexpected outcomes for others. Thus, it is recommended to analyze the impact of forwarding an NSH OAM packet for all OAM functions prior to enabling this behavior. The configurable parameterMUST be disabled by default.The actual format and additional processing of NSH OAM packets is outside the scope of this specification.