OAM for Service Programming with Segment Routing
Cisco Systems, Inc.
US
zali@cisco.com
Cisco Systems, Inc.
Belgium
cfilsfils@cisco.com
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park NC 27709
US
naikumar@cisco.com
Cisco Systems, Inc.
7200 Kit Creek Road
Research Triangle Park NC 27709-4987
US
cpignata@cisco.com
Cisco Systems, Inc.
France
fclad@cisco.com
Cisco Systems, Inc.
2000 Innovation Dr
Ottawa ON 3E8
Canada
faiqbal@cisco.com
Alibaba
xiaohu.xxh@alibaba-inc.com
Internet
spring
spring
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks.
defines data plane
functionality required to implement service segments and achieve service
programming in SR-enabled MPLS and IP networks, as described in the
Segment Routing architecture. This document defines the Operations,
Administrations and Maintenance (OAM) for service programming in
SR-enabled MPLS and IP networks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in .
This document uses the terminologies defined in ,
and so the readers are expected to be familiar with the same.
The initial focus of this document to define and document the machinery required to apply OAM mechanisms on SRv6 based service programming.
Future version of this document will include the required details to apply OAM mechanism on other data planes.
Section 4 of
introduces Service segments and the procedure of service programming when the
services are SR-aware and SR-unaware. By integrating the OAM functionality in the
services, versatile OAM tool kits can be used to execute programmable OAM for
service programming with Segment Routing.
This section describes the procedure to perform basic OAM mechanisms such as
path validation and path tracing of Service Programming environment in Segment
Routing network.
Any services upon receiving OAM packet may apply the service treatment if
it cannot differentiate the OAM packet from normal data packet. Depending on
the service type, service treatment on OAM packet may result in dropping the
OAM probe packet that may cause uncertainty in OAM mechanism.
To avoid such uncertainty, any node that is originating the OAM probe for
Service Programming OAM MUST mark the packet as OAM packet so that the
services can differentiate the OAM packet from data traffic.
As defined in section 4.1 of
, an SR-aware
service can process the SR information in the packet header such as performing
lookup or executing the next segment etc. An SR-aware
service may need to identify the packet payload and/or interpret SR
information to apply the right policy to the received packet. While processing
SR information in the packet header, it can process the OAM packet marker in
the SR header to differentiate the OAM packet from normal data packet.
An SR-aware service SHOULD skip applying the service on the OAM packet
while forwarding the packet to the next segment or IP address. As
defined in section 9, a local policy may be used to control any malicious use
of OAM marker.
As defined in section 4.2 of
, an SR-unaware
service may be a legacy service that is not able to process the SR information
in the packet header. SR Proxy, an entity that is external to the service is
used to handle the SR information processing on behalf of the service. SR
Proxy will remove the SR header before forwarding the packet to SR-unaware
services to avoid any erroneous decision due to the presence of SR header
that the service cannot recognize.
While processing SR information in the packet header, SR proxy can process
the OAM packet marker in the SR header to differentiate the OAM packet from
normal data packet. SR Proxy MUST skip forwarding the packets with OAM marker
to the service while forwarding the packet to the next segment or IP address.
As defined in section 9, a local policy may be used to control
any malicious use of OAM marker.
As mentioned in the above sections, SR-aware service or the SR proxy can
use the OAM marker to differentiate the OAM packet from data packet to skip
the
service treatment. Any intentional or unintentional use of OAM marker in data
traffic may result in skipping service treatment for data traffic. To avoid
such condition, a local policy will be used in the SR-aware service or SR
Proxy that SHOULD rate limit or MAY drop the packets received with OAM
marker.
defines
SRH.Flags.O-bit in SRH header. When service programming is implemented with SRv6
dataplane, SRH.Flags.O-bit is used as OAM marker. An IPv6 packet received with a local END.OP or END.OTP SID is also considered as an OAM packet.
Any node that is originating OAM probe to a service in SRv6 dataplane MUST set
SRH.Flags.O-bit in the SRH.
This section describes the availability of different tool kits that can be
used to perform OAM functionality for Service Programming with SRv6 dataplane.
An SR-aware service or SR proxy MUST implement the SRH.Flags.O bit.
An SR-aware service SHOULD skip applying the service to the packet when
SRH.Flags.O-bit is set and SHOULD forward the packet based on the next
header. SR Service Proxy MUST skip applying the service to the packet when
SRH.Flags.O-bit is set and SHOULD forward the packet based on the next
header.
An SR-aware service and SR proxy may choose to time-stamp and punt the
packet with SRH.Flags.O-bit set for further processing and this is a local
implementation matter.
Section 3.2 of [] defines OAM
segment ID and the associated forwarding semantics to implement the punt
behavior for OAM packets. Specifically, the draft defines END.OP and
END.OTP SIDs. An IPv6 packet received with DA set to a local END.OP or
END.OTP SID is considered as an OAM packet.
Any service policy head end MAY include OAM segment ID in the desired
segment list position of SRH. The inclusion of OAM SID in SRH can be used
to control the services that are required to punt the OAM packet for
processing.
There is no hardware or software changes required to use ICMP for Ping
operation. It can be triggered from the service policy head end or from
any classical IPv6 nodes by sending ICMPv6 Echo Request. The existing ICMP
Ping mechanism works seamlessly in SRv6 dataplane with no protocol changes
required to the standard ICMPv6 [],
[] or the standard ICMPv4
[].
An SR-aware service SHOULD skip the service and forward to next segment
based on the SR information in the packet header. An SR Service Proxy MUST skip the service and forward to next segment based on the SR information in the packet header.
When a remote node pings a service segment, it MUST set SRH.Flags.O = 1.
If the target service segment is implemented with USP behavior, the ICMP
packet can be constructed without adding END.OP or END.OTP SIDs defined
in . However, if the target service SID
observes a PSP behavior, the sender needs to insert END.OP/ END.OTP SIDs
before the target service SID in the segment-list. In either case, the
target SR-aware service or SR proxy receives the ICMP echo request with
either SRH.Flags.O-bit set or with the local END.OP or END.OTP SID.
In both cases, the packet is punted for slow-path processing and service is
skipped.
The Egress node process the packet as per procedure defined in
. The Egress checks if the target SID is
locally programmed or not.
If the target SID is not locally programmed, the Egress responses with
the ICMPv6 message (Type: "SRv6 OAM (TBA)", Code: "SID not
locally implemented (TBA)"); otherwise a success is returned
.
A classic traceroute mechanism relies on UDP probes by sending packets
with sequentially incrementing the TTL. More details are available in
section 4.3.1 of .
An SR-aware service or SR proxy upon receiving the probe with TTL=1,
may follow the traditional behavior of replying with ICMPv6 Time Exceeded
Message (Type 3) as defined in without applying the service.
Use of SRH.Flags.O bit and END.OP/ END.OTP SIDs as OAM marker in the UDP
probe for trace route is same as discussed for ICMPv6 ping discussed in
the last section.
A local policy may be used to control any malicious use of OAM marker.
More details are to be added in a future revision of the document.
Authors would like to thank Bruno Decraene for his review and
useful comments.