OAM Packet and Behavior in the Network
Service Header (NSH)
Orange
Rennes
35000
France
mohamed.boucadair@orange.com
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.
This document clarifies an ambiguity related to the definition of
Operations, Administration, and Maintenance (OAM) packet discussed in
.
The processing of the O bit in the Network Service Header (NSH) must
follow the updated behavior specified in .
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:
refers to 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 .
an NSH-aware element that is
capable of generating NSH OAM packets. An SFC data plane element may
behave as an OAM control element.
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.
refers to user packets cited in Section 5.7
of .
This document updates Section 2.2 of
as follows:
Setting this bit indicates an OAM packet
(see [RFC6291]). 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 and MUST
NOT be set for non-OAM packets. The O bit MUST 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, but MAY
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 parameter MUST be disabled by
default.
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, the last SFF of an SFP). The O bit MUST be set for NSH OAM packets and
MUST NOT be set for non-OAM packets. The O bit MUST NOT be
modified along the SFP.NSH-encapsulated
packets that include user data are not considered as 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 Proxies
SHOULD 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
identifier or 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
(including the order) of the SFC OAM data SHOULD be specified in
the relevant OAM or Context Header specification. SFC-aware SF/SFF/SFC Proxy/Classifier
implementations that do not support SFC OAM procedures SHOULD
discard packets with O bit set, but MAY 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 parameter MUST be disabled by
default. The actual format and
additional processing of NSH OAM packets is outside the scope of
this specification.
This document does not make any request to IANA.
Data plane SFC-related security considerations, including privacy,
are discussed in Section 6 of and Section
8 of . Additional security considerations
related to SFC OAM are discussed in Section 9 of .
Any data included in an NSH OAM packet SHOULD be integrity-protected
.
Thanks to Jim Guichard, Greg Mirsky, Joel Halpern, Christian
Jacquenet, Dirk von-Hugo, Carlos Pignataro, and Frank Brockners for the
comments.
Thanks to Barry Leiba for the art directorate review and Russ Housley
for the security directorate review.