Controlled Return Path for Service Function Chain (SFC) OAMIndividual contributorNo.889, BiBo RoadShanghai201203China+86 1772120928318555817@qq.comZTE Corp.1900 McCarthy Blvd. #205MilpitasCA95035USAgregimirsky@gmail.comChina TelecomNo.1835, South PuDong RoadShanghai201203China+86 1891858889718918588897@189.cn
Internet
SFC WGSFC, OAM
This document defines an extension to the Service Function Chain (SFC)
Operation, Administration and Maintenance (OAM) that enables control
of the Echo Reply return path directing it over a Reverse Service
Function Path. Enforcing the specific return path can be used to
verify the bidirectional connectivity of SFC and increase the robustness
of SFC OAM.
While Service Function Chain (SFC) Echo Request, defined in ,
always traverses the SFC it directed to, the
corresponding Echo Reply is sent over IP network . There are scenarios
when it is beneficial to direct the responder to use a path other than
the IP network. This document extends Service Function
Chain (SFC) Operation, Administration and Maintenance (OAM) by enabling
control of the Echo Reply return path to be directed over a Reply Service
Function Path (SFP). This document defines a new Type-Length-Value (TLV), Reply
Service Function Path TLV, for Reply via Specified Path mode of SFC Echo Reply ().
The Reply Service Function Path TLV can provide an efficient mechanism to test
SFCs, such as bidirectional and hybrid SFC, as defined in Section 2.2 .
For example, it allows an operator to test both directions of the bidirectional or
hybrid SFP with a single SFC Echo Request/Echo Reply operation.
SF - Service FunctionSFF - Service Function ForwarderSFC - Service Function Chain, an ordered set of some abstract SFs.SFP - Service Function PathSPI - Service Path IndexOAM - Operation, Administration, and Maintenance
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.
Following reply modes had been defined in :Do Not ReplyReply via an IPv4/IPv6 UDP PacketReply via Application Level Control ChannelReply via Specified Path
The Reply via Specified Path mode is intended to enforce the use of the
particular return path specified in the included TLV. This mode may
help to verify bidirectional continuity or increase the robustness of
the monitoring of the SFC by selecting a more stable path. In the case of
SFC, the sender of Echo Request instructs the destination SFF to send
Echo Reply message along the SFP specified in the SFC Reply Path
TLV as described in .
The SFC Reply Path TLV carries the information that sufficiently
identifies the return SFP that the SFC Echo Reply message is
expected to follow. The format of SFC Reply Path TLV is shown
in .
where:Reply Path TLV Type: is two octets long, indicates the TLV that
contains information about the SFC Reply path.Length: is two octets long, MUST be equal to 4Reply Service Function Path is used to describe the return path
that an SFC Echo Reply is requested to follow.The format of the Reply Service Function Path field displayed in
where:
Reply Service Function Path Identifier: SFP identifier for the path that
the SFC Echo Reply message is requested to be sent over.
Service Index: the value for the Service Index field.in the NSH
of the SFC Echo Reply message.
defined mechanism to control return path
for MPLS LSP Echo Reply. In case of SFC, the return path is an SFP along which SFC Echo
Reply message MUST be transmitted. Hence, the SFC Reply Path TLV included
in the SFC Echo Request message MUST sufficiently identify the SFP
that the sender of the Echo Request message expects the receiver to use
for the corresponding SFC Echo Reply.
When sending an Echo Request, the sender MUST set the value of Reply Mode field to
"Reply via Specified Path", defined in ,
and if the specified path is SFC path, the Request MUST include SFC Reply Path TLV.
The SFC Reply Path TLV includes the identifier of the reverse SFP and an appropriate Service Index.
Echo Reply is expected to be sent by the destination SFF of the SFP being tested or by the SFF
at which SFC TTL expires as defined .
The processing described below equally applies to both cases and referred to as responding SFF.
If the Echo Request message with SFC Reply Path TLV, received by the responding
SFF, has Reply Mode value of "Reply via Specified Path" but no SFC Reply Path TLV is present,
then the responding SFF MUST send Echo Reply with Return Code set to "Reply Path TLV is missing" value (TBA2).
If the responding SFF cannot find requested SFP it MUST send Echo Reply with Return Code set to
"Reply SFP was not found" and include the SFC Reply Path TLV from the Echo Request message.
The ability to specify the return path for an Echo Reply might be used in case of bi-directional
SFC. The egress SFF of the forward SFP may be not
co-located with a classifier of the reverse SFP, and thus the egress SFF has no
infrmation about the reverse path of an SFC. Because of that, even for bi-directional SFC, a
reverse SFP needs to be indicated in a Reply Path TLV in the Echo Request
message.
Security considerations discussed in apply to this document.
The SFC Return Path extension, defined in this document, can be used for
potential "proxying" attacks. For example, an initiator of the Echo Request
may specify a return path that has a destination different from that
of the initiator. But usually, such attacks will not happen in an
SFC domain where the initiators and receivers belong to the same
domain, as specified in .
Even if the attack occurs, in order to prevent using the SFC Return Path
extension for proxying any possible attacks, the return path
SFP SHOULD have a path to reach the sender of the Echo Request,
identified in SFC Source TLV .
The receiver MAY drop the Echo Request when it cannot
determine whether the return path SFP has the route to the
initiator. That means, when sending Echo Request, the sender
SHOULD choose a proper source address according to specified return
path SFP to help the receiver to make the decision.
IANA is requested to assign from its SFC Echo Request/Echo Reply TLV
registry new type as follows:
ValueDescriptionReferenceTBA1 SFC Reply Path Type This document
IANA is requested to assign new return codes from the SFC Echo
Request/Echo Reply Return Codes registry as following:
ValueDescriptionReferenceTBA2 Reply Path TLV is missing This documentTBA3 Reply SFP was not found This document