draft-ietf-sfc-multi-layer-oam-01.txt   draft-ietf-sfc-multi-layer-oam-02.txt 
SFC WG G. Mirsky SFC WG G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Updates: 8300 (if approved) W. Meng Updates: 8300 (if approved) W. Meng
Intended status: Standards Track ZTE Corporation Intended status: Standards Track ZTE Corporation
Expires: August 1, 2019 B. Khasnabish Expires: September 9, 2019 B. Khasnabish
Individual contributor Individual contributor
C. Wang C. Wang
January 28, 2019 March 8, 2019
Active OAM for Service Function Chains in Networks Active OAM for Service Function Chains in Networks
draft-ietf-sfc-multi-layer-oam-01 draft-ietf-sfc-multi-layer-oam-02
Abstract Abstract
A set of requirements for active Operation, Administration and A set of requirements for active Operation, Administration and
Maintenance (OAM) of Service Function Chains (SFCs) in networks is Maintenance (OAM) of Service Function Chains (SFCs) in networks is
presented. Based on these requirements an encapsulation of active presented. Based on these requirements an encapsulation of active
OAM message in SFC and a mechanism to detect and localize defects OAM message in SFC and a mechanism to detect and localize defects
described. Also, this document updates RFC 8300 in the definition of described. Also, this document updates RFC 8300 in the definition of
O (OAM) bit in the Network Service Header (NSH) and defines how the O (OAM) bit in the Network Service Header (NSH) and defines how the
active OAM message identified in SFC NSH. active OAM message identified in SFC NSH.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 August 1, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4
4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 5 4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 5
5. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7 5. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7
5.1. SFC Echo Request Transmission . . . . . . . . . . . . . . 8 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8
5.2. SFC Echo Request Reception . . . . . . . . . . . . . . . 9 5.2. SFC Echo Request Transmission . . . . . . . . . . . . . . 9
5.3. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 9 5.3. SFC Echo Request Reception . . . . . . . . . . . . . . . 9
5.4. Overlay Echo Reply Reception . . . . . . . . . . . . . . 10 5.4. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.5. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 11 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 12
8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 11 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 12
8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 12 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 13
8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 12 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 13
8.6. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 13 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 13
8.7. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 13 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC7665] defines components necessary to implement Service Function [RFC7665] defines components necessary to implement Service Function
Chain (SFC). These include a classifier which performs the Chain (SFC). These include a classifier which performs the
classification of incoming packets. A Service Function Forwarder classification of incoming packets. A Service Function Forwarder
(SFF) is responsible for forwarding traffic to one or more connected (SFF) is responsible for forwarding traffic to one or more connected
Service Functions (SFs) according to the information carried in the Service Functions (SFs) according to the information carried in the
SFC encapsulation. SFF also handles traffic coming back from the SF SFC encapsulation. SFF also handles traffic coming back from the SF
and transports the data packets to the next SFF. And the SFF serves and transports the data packets to the next SFF. And the SFF serves
skipping to change at page 4, line 8 skipping to change at page 4, line 8
NSH: Network Service Header NSH: Network Service Header
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
PRNG: Pseudorandom number generator PRNG: Pseudorandom number generator
RDI: Remote Defect Indication RDI: Remote Defect Indication
RSP: Rendered Service Path RSP: Rendered Service Path
SMI Structure of Management Information
SF: Service Function SF: Service Function
SFC: Service Function Chain SFC: Service Function Chain
SFF: Service Function Forwarder SFF: Service Function Forwarder
SFP: Service Function Path SFP: Service Function Path
3. Requirements for Active OAM in SFC Network 3. Requirements for Active OAM in SFC Network
skipping to change at page 4, line 34 skipping to change at page 4, line 36
|SF1| |SF2| |SF3| |SF4| |SF5| |SF6| |SF1| |SF2| |SF3| |SF4| |SF5| |SF6|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
\ / \ / \ / \ / \ / \ /
+----------+ +----+ +----+ +----+ +----------+ +----+ +----+ +----+
|Classifier|-------|SFF1|---------|SFF2|--------|SFF3| |Classifier|-------|SFF1|---------|SFF2|--------|SFF3|
+----------+ +----+ +----+ +----+ +----------+ +----+ +----+ +----+
Figure 1: SFC reference model Figure 1: SFC reference model
In the example presented in Figure 1, the service SFP1 may be In the example presented in Figure 1, the service SFP1 may be
realized through two RSPs, RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4-- realized through two independent RSPs, RSP1(SF1--SF3--SF5) and
SF5). To perform end-to-end (e2e) FM SFC OAM: RSP2(SF2--SF4--SF5). To perform end-to-end (e2e) FM SFC OAM:
REQ#1: Packets of active OAM in SFC SHOULD be fate sharing with REQ#1: Packets of active OAM in SFC SHOULD be fate sharing with
data traffic, i.e., in-band with the monitored traffic follow the data traffic, i.e., in-band with the monitored traffic follow the
same RSP, in the forward direction from ingress toward egress same RSP, in the forward direction from ingress toward egress
endpoint(s) of the OAM test. endpoint(s) of the OAM test.
REQ#2: SFC OAM MUST support pro-active monitoring of any element REQ#2: SFC OAM MUST support pro-active monitoring of any element
in the SFC availability. in the SFC availability.
The egress, SFF3 in the example in Figure 1, is the entity that The egress, SFF3 in the example in Figure 1, is the entity that
skipping to change at page 7, line 9 skipping to change at page 7, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SFC Active OAM Control Packet ~ ~ SFC Active OAM Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFC Active OAM Header Figure 2: SFC Active OAM Header
V - two bits long field indicates the current version of the SFC V - two bits long field indicates the current version of the SFC
active OAM header. The current value is 0. active OAM header. The current value is 0.
Msg Type - six bits long field identifies OAM protocol, e.g., Echo Msg Type - six bits long field identifies OAM protocol, e.g., Echo
Request/Reply or BFD. Request/Reply or Bidirectional Forwarding Detection.
Flags - eight bits long field carries bit flags that define Flags - eight bits long field carries bit flags that define
optional capability and thus processing of the SFC active OAM optional capability and thus processing of the SFC active OAM
control packet, e.g., optional timestamping. control packet, e.g., optional timestamping.
Length - two octets long field that is the length of the SFC Length - two octets long field that is the length of the SFC
active OAM control packet in octets. active OAM control packet in octets.
5. Echo Request/Echo Reply for SFC in Networks 5. Echo Request/Echo Reply for SFC in Networks
skipping to change at page 8, line 27 skipping to change at page 8, line 27
Sender's Handle field. The value of the Sender's Handle field Sender's Handle field. The value of the Sender's Handle field
SHOULD NOT be changed in the course of the test session. SHOULD NOT be changed in the course of the test session.
The Sequence Number is assigned by the sender and can be (for The Sequence Number is assigned by the sender and can be (for
example) used to detect missed replies. The value of the Sequence example) used to detect missed replies. The value of the Sequence
Number field SHOULD be monotonically increasing in the course of Number field SHOULD be monotonically increasing in the course of
the test session. the test session.
TLVs (Type-Length-Value tuples) have the two octets long Type TLVs (Type-Length-Value tuples) have the two octets long Type
field, two octets long Length field that is the length of the field, two octets long Length field that is the length of the
Value field in octets. Value field in octets. Type values, see Section 8.7, less than
32768 identify mandatory TLVs that MUST either be supported by an
implementation or result in the Return Code of 2 ("One or more of
the TLVs was not understood") being sent in the echo response.
Type values greater than or equal to 32768 identify optional TLVs
that SHOULD be ignored if the implementation does not understand
or support them. If a Type value for TLV or sub-TLV is in the
range for Vendor Private Use, the Length MUST be at least 4, and
the first four octets MUST be that vendor's the Structure of
Management Information (SMI) [RFC1423] Private Enterprise Number,
in network octet order. The rest of the Value field is private to
the vendor.
5.1. SFC Echo Request Transmission 5.1. Return Codes
The Return Code is set to zero by the sender of an echo request. The
receiver of said echo request can set it to one of the values listed
below in the corresponding echo reply that it generates.
Value Meaning
----- -------
0 No Return Code
1 Malformed echo request received
2 One or more of the TLVs was not understood
5.2. SFC Echo Request Transmission
SFC echo request control packet MUST use the appropriate SFC echo request control packet MUST use the appropriate
encapsulation of the monitored SFP. If Network Service Header (NSH) encapsulation of the monitored SFP. If Network Service Header (NSH)
is used, echo request MUST set O bit, as defined in [RFC8300]. SFC is used, echo request MUST set O bit, as defined in [RFC8300]. SFC
NSH MUST be immediately followed by the SFC Active OAM Header defined NSH MUST be immediately followed by the SFC Active OAM Header defined
in Section 4. Message Type field in the SFC Active OAM Header MUST in Section 4. Message Type field in the SFC Active OAM Header MUST
be set to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2. be set to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2.
Value of the Reply Mode field MAY be set to: Value of the Reply Mode field MAY be set to:
o Do Not Reply (TBA5) if one-way monitoring is desired. If the echo o Do Not Reply (TBA5) if one-way monitoring is desired. If the echo
request is used to measure synthetic packet loss; the receiver may request is used to measure synthetic packet loss; the receiver may
report loss measurement results to a remote node. report loss measurement results to a remote node.
o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the
most used. most used.
o Reply via Application Level Control Channel (TBA7) value if the o Reply via Application Level Control Channel (TBA7) value if the
SFP may have bi-directional paths. SFP may have bi-directional paths.
o Reply via Specified Path (TBA7) value to enforce the use of the o Reply via Specified Path (TBA8) value to enforce the use of the
particular return path specified in the included TLV to verify bi- particular return path specified in the included TLV to verify bi-
directional continuity and also increase the robustness of the directional continuity and also increase the robustness of the
monitoring by selecting a more stable path. monitoring by selecting a more stable path.
5.2. SFC Echo Request Reception 5.3. SFC Echo Request Reception
5.3. SFC Echo Reply Transmission Sending an SFC echo request to the control plane is triggered by one
of the following packet processing exceptions: NSH TTL expiration,
NSH Service Index (SI) expiration or the receiver is the terminal SFF
for an SFP.
Firstly, the SFF that has received an SFC echo request verifies the
general sanity of the received packet. If the packet is not well-
formed, the receiver SFF SHOULD send an SFC echo reply with the
Return Code set to "Malformed echo request received" and the Subcode
set to zero. If there are any TLVs not marked as "Ignore" (i.e., if
the TLV type is less than 32768, see Section 3) that SFF does not
understand, the SFF SHOULD send an SFC echo reply with the Return
Code set to "TLV not understood" and set the Subcode to zero. In the
latter case, the SFF SHOULD include an Errored TLVs TLV that as sub-
TLVs contains only the misunderstood TLVs. The header field's
Sender's Handle, Sequence Number are not examined but are included in
the SFC echo reply message.
5.4. SFC Echo Reply Transmission
The Reply Mode field directs whether and how the echo reply message The Reply Mode field directs whether and how the echo reply message
should be sent. The sender of the echo request MAY use TLVs to should be sent. The sender of the echo request MAY use TLVs to
request that the corresponding echo reply is transmitted over the request that the corresponding echo reply is transmitted over the
specified path. Value TBA3 is referred to as "Do not reply" mode and specified path. Value TBA3 is referred to as "Do not reply" mode and
suppresses transmission of echo reply packet. The default value suppresses transmission of echo reply packet. The default value
(TBA6) for the Reply mode field requests the responder to send the (TBA6) for the Reply mode field requests the responder to send the
echo reply packet out-of-band as IPv4 or IPv6 UDP packet. echo reply packet out-of-band as IPv4 or IPv6 UDP packet.
Responder to the SFC echo request sends the echo reply over IP Responder to the SFC echo request sends the echo reply over IP
skipping to change at page 9, line 40 skipping to change at page 10, line 36
| SFC OAM Source ID Type | Length | | SFC OAM Source ID Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SFC Source TLV Figure 4: SFC Source TLV
where where
SFC OAM Source Id Type is two octets in length and has the value SFC OAM Source Id Type is two octets in length and has the value
of TBA9 Section 8.6. of TBA9 Section 8.7.
Length is two octets long field, and the value equals the length Length is two octets long field, and the value equals the length
of the Value field in octets. of the Value field in octets.
Value field contains the IP address of the sender of the SFC OAM Value field contains the IP address of the sender of the SFC OAM
control message, IPv4 or IPv6. control message, IPv4 or IPv6.
The UDP destination port for SFC Echo Reply TBA10 will be allocated The UDP destination port for SFC Echo Reply TBA10 will be allocated
by IANA Section 8.7. by IANA Section 8.8.
5.4. Overlay Echo Reply Reception 5.5. SFC Echo Reply Reception
An SFF SHOULD NOT accept SFC echo reply unless the received passes
the following checks:
o the received SFC echo reply is well-formed;
o it has outstanding SFC echo request sent from the UDP port that
matches destination UDP port number of the received packet;
o if the matching to the echo request found, the value of Sender's
Handle n the echo request sent is equal to the value of Sender's
Handle in the echo reply received;
o if all checks passed, the SFF checks if the Sequence Number in the
echo request sent matches to the Sequence Number in the echo reply
received.
6. Security Considerations 6. Security Considerations
Overlay Echo Request/Reply operates within the domain of the overlay Overlay Echo Request/Reply operates within the domain of the overlay
network and thus inherits any security considerations that apply to network and thus inherits any security considerations that apply to
the use of that overlay technology and, consequently, underlay data the use of that overlay technology and, consequently, underlay data
plane. Also, the security needs for SFC echo request/reply are plane. Also, the security needs for SFC echo request/reply are
similar to those of ICMP ping [RFC0792], [RFC4443] and MPLS LSP ping similar to those of ICMP ping [RFC0792], [RFC4443] and MPLS LSP ping
[RFC8029]. [RFC8029].
skipping to change at page 10, line 42 skipping to change at page 12, line 8
Number of an outstanding SFC echo request message which is highly Number of an outstanding SFC echo request message which is highly
unlikely. Thus the non-matching reply would be discarded. unlikely. Thus the non-matching reply would be discarded.
To protect against unauthorized sources trying to obtain information To protect against unauthorized sources trying to obtain information
about the overlay and/or underlay an implementation MAY check that about the overlay and/or underlay an implementation MAY check that
the source of the echo request is indeed part of the SFP. the source of the echo request is indeed part of the SFP.
7. Acknowledgments 7. Acknowledgments
Authors greatly appreciate thorough review and the most helpful Authors greatly appreciate thorough review and the most helpful
comments from Dan Wing. comments from Dan Wing and Dirk von Hugo.
8. IANA Considerations 8. IANA Considerations
8.1. SFC Active OAM Protocol 8.1. SFC Active OAM Protocol
IANA is requested to assign a new type from the SFC Next Protocol IANA is requested to assign a new type from the SFC Next Protocol
registry as follows: registry as follows:
+-------+----------------+---------------+ +-------+----------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
skipping to change at page 13, line 5 skipping to change at page 14, line 24
| TBA8 | Reply via Specified Path | This document | | TBA8 | Reply via Specified Path | This document |
| TBA8+1-191 | Unassigned | IETF Review | | TBA8+1-191 | Unassigned | IETF Review |
| 192-251 | Unassigned | First Come First | | 192-251 | Unassigned | First Come First |
| | | Served | | | | Served |
| 252-254 | Unassigned | Private Use | | 252-254 | Unassigned | Private Use |
| 255 | Reserved | | | 255 | Reserved | |
+------------+---------------------------------+--------------------+ +------------+---------------------------------+--------------------+
Table 5: SFC Echo Reply Modes Table 5: SFC Echo Reply Modes
8.6. SFC TLV Type 8.6. SFC Echo Return Codes
IANA is requested to create in the SFC Echo Request/Echo Reply
Parameters registry the new sub-registry Return Codes:
+---------+-------------+-------------------------+
| Value | Description | Reference |
+---------+-------------+-------------------------+
| 0-191 | Unassigned | IETF Review |
| 192-251 | Unassigned | First Come First Served |
| 252-254 | Unassigned | Private Use |
| 255 | Reserved | |
+---------+-------------+-------------------------+
Table 6: SFC Echo Return Codes
Return Codes defined in this document are the following:
Value Meaning
----- -------
0 No Return Code
1 Malformed echo request received
2 One or more of the TLVs was not understood
8.7. SFC TLV Type
IANA is requested to create SFC OAM TLV Type registry. All code IANA is requested to create SFC OAM TLV Type registry. All code
points in the range 1 through 32759 in this registry shall be points in the range 1 through 32759 in this registry shall be
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
[RFC8126]. Code points in the range 32760 through 65279 in this [RFC8126]. Code points in the range 32760 through 65279 in this
registry shall be allocated according to the "First Come First registry shall be allocated according to the "First Come First
Served" procedure as specified in [RFC8126]. Remaining code points Served" procedure as specified in [RFC8126]. Remaining code points
are allocated according to the Table 6: are allocated according to the Table 7:
+---------------+--------------+-------------------------+ +---------------+-------------------------+-------------------------+
| Value | Description | Reference | | Value | Description | Reference |
+---------------+--------------+-------------------------+ +---------------+-------------------------+-------------------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| 1- 32759 | Unassigned | IETF Review | | 1- 32767 | Mandatory TLV, | IETF Review |
| 32760 - 65279 | Unassigned | First Come First Served | | | unassigned | |
| 65280 - 65519 | Experimental | This document | | 32768 - 65279 | Optional TLV, | First Come First Served |
| 65520 - 65534 | Private Use | This document | | | unassigned | |
| 65535 | Reserved | This document | | 65280 - 65519 | Experimental | This document |
+---------------+--------------+-------------------------+ | 65520 - 65534 | Private Use | This document |
| 65535 | Reserved | This document |
+---------------+-------------------------+-------------------------+
Table 6: SFC TLV Type Registry Table 7: SFC TLV Type Registry
This document defines the following new value in SFC OAM TLV Type This document defines the following new value in SFC OAM TLV Type
registry: registry:
+-------+-------------------+---------------+ +-------+-------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------+---------------+ +-------+-------------------+---------------+
| TBA9 | Source IP Address | This document | | TBA9 | Source IP Address | This document |
+-------+-------------------+---------------+ +-------+-------------------+---------------+
Table 7: SFC OAM Source IP Address Type Table 8: SFC OAM Source IP Address Type
8.7. SFC OAM UDP Port 8.8. SFC OAM UDP Port
IANA is requested to allocate UDP port number according to IANA is requested to allocate UDP port number according to
+--------+-------+-----------+-------------+------------+-----------+ +--------+-------+-----------+-------------+------------+-----------+
| Servic | Port | Transport | Description | Semantics | Reference | | Servic | Port | Transport | Description | Semantics | Reference |
| e Name | Numbe | Protocol | | Definition | | | e Name | Numbe | Protocol | | Definition | |
| | r | | | | | | | r | | | | |
+--------+-------+-----------+-------------+------------+-----------+ +--------+-------+-----------+-------------+------------+-----------+
| SFC | TBA10 | UDP | SFC OAM | Section | This | | SFC | TBA10 | UDP | SFC OAM | Section | This |
| OAM | | | | 5.3 | document | | OAM | | | | 5.4 | document |
+--------+-------+-----------+-------------+------------+-----------+ +--------+-------+-----------+-------------+------------+-----------+
Table 8: SFC OAM Port Table 9: SFC OAM Port
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 29 skipping to change at page 16, line 29
"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>.
9.2. Informative References 9.2. Informative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers",
RFC 1423, DOI 10.17487/RFC1423, February 1993,
<https://www.rfc-editor.org/info/rfc1423>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
 End of changes. 27 change blocks. 
51 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/