Network Working Group C. Li
Internet-Draft M. Chen
Intended status: Standards Track Huawei
Expires: September 6, 2018 March 5, 2018
Passive Performance Measurement for SRv6 Network Programming
draft-li-spring-passive-pm-for-srv6-np-00
Abstract
This document defines a passive performance measurement method for
SRv6 network programming. In this method, performance measurement
information can be carried in data packets by two ways. One way is
carrying measurement information by used SIDs. Another way is
carrying measurement information via related SRH TLVs.
Requirements Language
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 RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
Li & Chen Expires September 6, 2018 [Page 1]
Internet-Draft Passive PM for SRv6 NP March 2018
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Passive SRv6 Performace Measurement . . . . . . . . . . . . . 4
4. SRH Flags for PM . . . . . . . . . . . . . . . . . . . . . . 5
4.1. DM-bit for Delay Measurement . . . . . . . . . . . . . . 5
4.2. LM-bit for Loss Measurement . . . . . . . . . . . . . . . 6
5. Optional TLVs . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Path ID TLV . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Block ID TLV . . . . . . . . . . . . . . . . . . . . . . 9
5.3. DM TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. LM TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Delay Measurement procedures . . . . . . . . . . . . . . 12
6.1.1. Using SIDs . . . . . . . . . . . . . . . . . . . . . 12
6.1.2. Using DM TLV . . . . . . . . . . . . . . . . . . . . 13
6.2. Loss Measurement procedures . . . . . . . . . . . . . . . 14
6.2.1. Using SIDs . . . . . . . . . . . . . . . . . . . . . 14
6.2.2. Using LM TLV . . . . . . . . . . . . . . . . . . . . 15
6.3. End.IOAM . . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Segment routing (SR) [I-D.ietf-spring-segment-routing] is a source
routing paradigm that explicitly indicates the forwarding path for
packets at the ingress node by inserting an ordered list of
instructions, called segments. A segment can represent a topological
or service-based instruction. Segment routing allows a node to steer
packets based on segments.
When segment routing is deployed on IPv6 dataplane, called
SRv6[I-D.ietf-6man-segment-routing-header], a segment is a 128 bit
value, and it can be an IPv6 address of a local interface but it does
Li & Chen Expires September 6, 2018 [Page 2]
Internet-Draft Passive PM for SRv6 NP March 2018
not have to. As defined at
[I-D.filsfils-spring-srv6-network-programming], a segment has the
format of LOC: FUNCT. The most significant L bits is LOC that is
routable and leads packets to the SID originating node. The least
significant 128-L bits is the value of FUNCT that defines the local
actions of SID. L is the length of LOC and it is flexible. For
supporting SR, an extended header called Segment Routing Header
(SRH), which contains a list of SIDs and several needed information
such as Segment Left, has been defined in
[I-D.ietf-6man-segment-routing-header].
In most cases, a SRv6 segment will not be reused for routing again
after it has been updated to IPv6 destination address. But these
used SIDs will be carried in the packet to the egress node unless PSP
is enable. Therefore, these SIDs can be reused for other purposes
such as carring performance measurement information or IOAM
[I-D.ietf-ippm-ioam-data] information.
This document introduces a passive SRv6 network programming based
performance measurement. In this method, the performance measurement
information can be carried in data packets without extra OAM packets.
There are two options to carry the performance measurement
information in the data packets: using SIDs and using TLVs. Using
SIDs to carry performance measurement information will reuse the SID
space and does no require any extra space. Therefore, it is a light
weight SRv6 network programming based performance measurement method
or even a light weight SRv6 network programming based IOAM.
2. Terminology
This memo makes use of the terms defined in
[I-D.ietf-spring-segment-routing], [I-D.ietf-ippm-ioam-data] and
[I-D.filsfils-spring-srv6-network-programming]. It also introduces
the following terminologies.
PM: Performance measurement.
DM: Delay measurement.
LM: Packet Loss measurement.
DA: Destination Address
MI: Measurement Information
PMI: Performance Measurement Information
NMS: Network Management System
Li & Chen Expires September 6, 2018 [Page 3]
Internet-Draft Passive PM for SRv6 NP March 2018
3. Passive SRv6 Performace Measurement
This document defines a passive SRv6 performance measurement method
including delay measurement and packet loss measurement.
For delay measurement (DM), timestamp will be carried in the data
packet. For end-to-end DM, only the ingress node sending timestamp
needs to be carried in the data packet while all the timestamps of
each endpoint node along the path need to be carried for per-hop DM.
The timestamp will be used for calculating the delay by the egress
node or a controller, and the algorithm is the same as defined at
[RFC6374]. This documents proposes two options to carry timestamps:
using SIDs and using DM TLV. For achieving DM, this document defines
a new SRH flag DM bit.
For LM, counters associated with block[RFC8321] should be set. The
packets coloring and counting mechanism are the same as defined at
[RFC8321]. For identifying a block which the packet belongs to, a
Block ID TLV is proposed by this document. There are two options to
collect counters.The first one is sending counter values to NMS or
controller by nodes periodically. This option will be discussed at
later version of this document or another document. This document
will describe the second option, carrying counter values by packets
to the egress node and sending to controller or calculating by the
egress node. For achieving LM, this document defines a new SRH flag
LM bit.
A Block ID TLV should be carried by each data packets for packet
accounting when packet loss measurement is enable. The LM bit can be
set periodically at packets of a flow, so that corresponding counter
values can be obtained. Some packets without payload MUST be sent so
that the counter of last block can be obtained if there is no data
packet to carry PMI. This meachanism will be discussed at the later
version of this document.
For solving the problem of packet misorder, a data packet can carry
the counter value of the previous block, which means a sufficient
margin should be considered between the end of the block and reading
of counter. For solving the problem of lossing the data packets with
LM data, multiple data packets with LM data can be sent in a block.
These meachanisms will be discussed at the future version.
For end-to-end LM, only the ingress node counter value needs to be
carried in data packets. But counter values of each endpoint node
along the path need to be carried for per-hop LM. The counter value
will be used for calculating the packet loss by the egress node or a
controller, and the algorithm is the same as defined at [RFC6374].
Li & Chen Expires September 6, 2018 [Page 4]
Internet-Draft Passive PM for SRv6 NP March 2018
As well as DM, LM has two options to carry performance measurement
information(PMI): using SIDs and using LM TLV.
For option of using SIDs, PMI can be carried by the last 64 bits of
SIDs. In SRv6, a SID will not be used for routing after it has been
updated to IPv6 destination address (DA), so it can be rewrote with
metadata such as PMI. But for identifying nodes of SR path, the LOC
part of SID needs to remain still if there is no path ID to identify
a path, so only the non-LOC part can be rewrote with PMI. In this
draft, we assume the value of length of LOC is 64 or less when there
is no path ID in SRH since PMI need to meet the accuracy requirement
as defined at [I-D.ietf-ippm-ioam-data]. For getting rid of the
limitation of keeping LOC part of SIDs, a Path ID TLV is defined at
this documents. Using SID to carry PMI is a light weight passive PM
method for SRv6, and it also can be a light weight IOAM for SRv6.
For options of using TLVs, this documents defines DM TLV and LM TLV
in SRH to carry the PMI.
Futhermore, for punting a copied packet at a specific node, a new SID
is proposed at Section 6.3, called End.IOAM.
4. SRH Flags for PM
For measuring delay and packet loss, this draft defines 2 new flags
in SRH:
o DM-bit (Delay Measurement): Flag for Delay Measurement.
o LM-bit (Loss Measurement): Flag for Loss Measurement..
The recommended locations of DM-bit and LM-bit in SRH.Flag shows
below.
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| U| P| O| A| H|DM|LM| U|
+--+--+--+--+--+--+--+--+
The rest of this section will describe more detailed information of
these two flags.
4.1. DM-bit for Delay Measurement
The "Delay Measurement bit (DM-bit for short)" is a new flag in SRH.
The SRH.Flags.DM implements the "record timestamp and punt the copied
packet at the egress node" behavior. When a node N receives an SRv6
packet, N does following actions for processing DM-bit:
Li & Chen Expires September 6, 2018 [Page 5]
Internet-Draft Passive PM for SRv6 NP March 2018
1.If DM-bit = 1:
2. Get the receving timestamp T1 ASAP.
3. If SL=1 and DA is End.S or if SL=0: ;;Ref1
4. Punt a copied packet with T1 to CPU for further processing;;Ref2
5. Else:
6. If DM TLV:
7 If I-flag = 1:
8. Write T1 into DM TLV
9. Else:
10. Insert following code after the instruction of updating DA:
11. Update SRH[SL][64:] with the T1 ;;Ref3
o Ref1: If SL is 0 or SL is 1 and the DA is an End.S
[I-D.filsfils-spring-srv6-network-programming], meaning the
current node is the egress node, the node will punt a copied
packet with the timestamp to CPU for further processing. Else,
the node, which a middle node only inserts "updates the SID with
current timestamp" after the instruction of "update DA with
SRH[SL]" or write the timestamp into DM TLV if the I-flag is set.
The ralated timestamp at the ingress node should be wrote into SID
or DM TLV accordingly before sending the data packet.
o Ref2: At the egress node, in order to not affect the packet
forwarding, a copied data packet should be punted instead of the
datda packet itself. But this document does not limit
implementation to punt the entire packet or only headers of
packet.
o Ref3: If no DM TLV appears in SRH, the last 64 bits of SID SRH[SL]
is rewrote with current timestamp after updating SID SRH[SL] to
IPv6 DA. If there is no Path ID TLV in SRH, the locator part
needs to remain for identifying a SID. The 64-bits timestamp
meets the accuracy requirement of IOAM [I-D.ietf-ippm-ioam-data].
If a node does not support the DM-bit, then it simply ignores it upon
reception. If a node supports the DM-bit, it SHOULD advertise its
capability via node capability advertisement in IGP [ID.TBA].
When DM-bit is set, PSP flavor can not be enable since the SRH needs
to be punted at the egress node. Likewise, implementation of USP
should be executed after DM-flag's implementation because of the same
reason.
4.2. LM-bit for Loss Measurement
The "Loss Measurement bit (LM-bit for short)" is a new flag in SRH.
The SRH.Flags.LM implements the"record value of counter and punt the
Li & Chen Expires September 6, 2018 [Page 6]
Internet-Draft Passive PM for SRv6 NP March 2018
copied packet at the egress node" behavior. When a node N receives
an SRv6 packet, N does following actions for processing LM-bit:
1.If LM-bit = 1:
2. Record the value of corresponding counter as C1
3. If SL=1 and DA is End.S or if SL=0: ;;Ref1
4. Punt a copied packet with C1 to CPU for further processing;;Ref2
5. Else:
6. If LM TLV:
7 If I-flag = 1:
8. Write C1 into LM TLV
9. Else:
10. Insert following code after the instruction of updating DA:
11. Update SRH[SL][64:] with the C1 ;;Ref3
o Ref1: If SL is 0 or SL is 1 and the DA is an End.S
[I-D.filsfils-spring-srv6-network-programming], meaning the
current node is the egress node, the node will punt a copied
packet with the related counter's value to CPU for further
processing. Else, the node, which is a middle node only inserts
"updates the SID with current value of counter" after the
instruction of "update DA with SRH[SL]" or or write the counter
value into LM TLV if the I-flag is set. The related counter value
at the ingress node should be wrote into SID or DM TLV accordingly
before sending the data packet.
o Ref2: At the egress node, in order to not affect the packet
forwarding, a copied data packet should be punted instead of the
data packet itself. But this document does not limit
implementation to punt the entire packet or only headers of
packet. For measuring correctly, a Block ID TLV SHALL be carried
in SRH.
o Ref3: If no LM TLV appears in SRH, the last 64 bits of SID SRH[SL]
is rewrote with current value of counter associated to a path or a
flow after updating the SID SRH[SL] to IPv6 DA. If there is no
Path ID TLV in SRH, the locator part needs to remain for
identifying a SID. The key of counter can be SID list or path ID
or other ID such as flow label
[I-D.fioccola-spring-flow-label-alt-mark] that can identify a SID
path or a flow. However, a SID can be the key for a single hop
packet loss measurement.
If a node does not support the LM-bit, then it simply ignores it upon
reception. If a node supports the LM-bit, it SHOULD advertise its
capability via node capability advertisement in IGP [ID.TBA].
Li & Chen Expires September 6, 2018 [Page 7]
Internet-Draft Passive PM for SRv6 NP March 2018
When LM-bit is set, PSP flavor can not be enable since the SRH needs
to be punted at the egress node. Likewise, implementation of USP
should be executed after LM-flag's implementation because of the same
reason.
5. Optional TLVs
5.1. Path ID TLV
For easier identifying an SR path, this document defines a new Path
ID TLV, which identifies an SR path beginning from the ingress node.
If the path ID is a global ID, it can identfiy a path within an SR
domain then. If the path ID is a local ID assigned by an ingress
node, a tuple <Ingress ID, Path ID> can identify a single path within
an SR domain. The Ingress ID can be the ingress node SID or other ID
that can identify ingress uniquely within an SR domain. With a Path
ID TLV, the whole SID space can be reused for carrying metadata since
the path information will be indicated by the path ID. The global
path ID or tuple of <Ingress ID, Path ID> can be the key of counter
for packet loss measurement. The Path ID TLV has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flag | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: to be assigned by IANA (suggested value 7).
o Length: 6.
o Flag: 8 bits of flags. Following flags are defined:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| Reserved | G|
+--+--+--+--+--+--+--+--+
G-Flag: Global flag. Set when the path ID is a global path ID.
o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
ignored on receipt.
Li & Chen Expires September 6, 2018 [Page 8]
Internet-Draft Passive PM for SRv6 NP March 2018
o Path ID: 32 bits. Defines a unique path beginning from the
ingress node.
With a Path ID TLV, the entire SID space can be reused without
limitation of keeping LOC part.
5.2. Block ID TLV
Marking packets with difference colors as a block is a packet loss
measurement method proposed at [RFC8321]. A block ID describes a
block which the packet belongs to. This document defines a new Block
ID TLV, and it has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED | Block ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: to be assigned by IANA (suggested value 8).
o Length: 2.
o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
ignored on receipt.
o Block ID: 8 bits. Defines a block which the packet belongs to.
5.3. DM TLV
Delay measurement information can be carried by DM TLV. The
timestamp type is the same as defined at [I-D.ietf-ippm-ioam-data].
DM TLV will appear only once in SRH, the first one will be processed
while the rests will be ignored. The DM TLV has the following
format:
Li & Chen Expires September 6, 2018 [Page 9]
Internet-Draft Passive PM for SRv6 NP March 2018
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type | length | Flag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp n |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: to be assigned by IANA (suggested value 9).
o Length: 8-bit unsigned integer. This field specifies the length
of data added by each node in multiples of 4-octets.
o Flag: 8 bits of flags. Following flags are defined:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| Reserved | I|
+--+--+--+--+--+--+--+--+
I-Flag: IOAM flag. Set when the the measurment mode is IOAM mode.
If it is not set, only one timestamp will be carried at this DM TLV,
which is a 64 bits sending timestamp at the ingress node. Thus, the
middle nodes will not write the timestamp into DM TLV.
o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
ignored on receipt.
o Timestamp 1: 64 bits sending timestamp at the ingress node.
o Timestamp n: 64 bits receving timestamp at a specific node n.
5.4. LM TLV
Loss measurement information can be carried by LM TLV. LM TLV will
appear only once in SRH, the first one will be processed while the
rests will be ignored. The LM TLV has the following format:
Li & Chen Expires September 6, 2018 [Page 10]
Internet-Draft Passive PM for SRv6 NP March 2018
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type | length | Flag | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Coutner 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter n |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
o Type: to be assigned by IANA (suggested value 10).
o Length: 8-bit unsigned integer. This field specifies the length
of data added by each node in multiples of 4-octets.
o Flag: 8 bits of flags. Following flags are defined:
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| Reserved | I|
+--+--+--+--+--+--+--+--+
I-Flag: IOAM flag. Set when the the measurment mode is IOAM mode.
If it is not set, only one counter will be carried at this LM TLV,
which is a 64 bit counter value of pakcets in corresponding block at
the ingress node. Thus, the middle nodes will not write the counter
value into DM TLV.
o RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
ignored on receipt.
o Counter 1: 64 bits counter value of packets in corresponding block
at the ingress node.
o Counter n: 64 bits counter value of packets in corresponding block
at the ingress node at a specific node n.
Li & Chen Expires September 6, 2018 [Page 11]
Internet-Draft Passive PM for SRv6 NP March 2018
6. Operations
This section will describe detailed operations of passive SRv6
network programming based performance measurement. For easy
understanding, the following simple topology is used for
illustration.
CE-A ---- N1-----N2-----N3---- CE-B
Reference Topology
In the reference topology:
o Nodes N1, N2, and N3 are all SRv6 capable nodes.
o Node N1 and N3 are configured with a tenant 10, each connected to
CE-A and CE-B respectively.
o Node Nk has Ak::/68 for its local SID space from which Local SIDs
are explicitly allocated.
o A2::1 is an End function allocated by N2
o A3::D10 is an End.DT4 function bound to tenant IPv4 table 10
allocated by N3.
o Bk::/64 is the loopback address of node K for IGP.
Assuming that the measured flow from CE-A to CE-B will travel path
<N1, N2, N3>. The ingress node N1 will insert a SRH with SID list
<A2::1, A3::D10> into the IPv6 header when it receives a IPv4 packet
with SA is CE-A, and DA is CE-B, so the packet header is (B1, DA)
(A3::D10, A2::1, SL=2)(CE-A, CE-B). The DA of IPv6 header is waiting
to be reworte by the active segment.
6.1. Delay Measurement procedures
For measuring delay, there are two options. In both options, DM-bit
needs to be set. If there is a DM TLV in SRH, PMI will be carried by
DM TLV. Otherwise, the PMI will be carried by SIDs.
6.1.1. Using SIDs
If choosing the option of using SIDs to carry delay MI, the
SRH.Flag.DM-bit needs to be set, and DM TLV MUST NOT appear in SRH.
After updating IPv6 DA with A2::1, the ingress node N1 updates SID
A2::1 in SRH with current timestamp and then forwards packet to N2
Li & Chen Expires September 6, 2018 [Page 12]
Internet-Draft Passive PM for SRv6 NP March 2018
according to matched FIB entries. Assuming that the timestamp value
is T1, then the updated packet header becomes (B1, A2::1) (A3::D10,
A2::T1, SL=1) (CE-A, CE-B).
When N2 receives the packet with DA A2::1 which is an End SID
originated by N2, N2 will insert "Update SRH[SL][64:] with the
current timestamp" after instruction of "update DA with SRH[SL]", and
then process this End SID.
After updating IPv6 DA with SRH[0] A::D10, the current timestamp will
be recorded at the last 64 bits of End SID A3::D10. Assuming that
the timestamp value is T2, the updated packet header becomes (B1,
A3::D10) (A3::T2, A2::T1, SL=0) (CE-A, CE-B). According to the
updated DA A3::D10, the packet will be forwarded to N3.
When the egress node N3 receives the packet with header (B1, A3::D10)
(A3::T2, A2::T1, SL=0) (CE-A, CE-B), N3 should timestamp the copied
packet and punt it to CPU for further processing since SRH.SL is 0
meaning the packet has reached the egress node. Then, N3
decapsulates the outer header and forwards the inner packet to CE-B
based on the routes in tenant-10 IPv4 table since the DA is a local
End.DT4 SID.
Measurement can be implemented by node or a remote controller. The
algorithm of delay measurement is the same as defined at [RFC6374].
However, in this solution, only one receiving timestamp or sending
timestamp can be recorded in SID at each endpoint node. Therefore,
it is RECOMMENDED that the ingress node records the sending timestamp
while the other nodes record the receiving timestamp. Therefore,
end-to-end delay measurement can be measured accurately. But for
middle nodes, the delay for a single hop is the sum of previous
node's processing delay and link delay between two nodes instead of
link delay only.
6.1.2. Using DM TLV
If choosing the option of using DM TLV to carry delay MI, and the
SRH.Flag.DM-bit needs to be set, and a DM TLV needs to be inserted in
SRH with the flag set accordingly.
Using the DM TLV will not affect the processing of SIDs. But before
sending a data packet, the ingress node N1 will write the sending
timestamp into DM TLV. When a middle node N2 receives a data packet,
it will inspect the existence of DM TLV. If there is a DM TLV in SRH
and the SRH.DM.I-flag is set, then a timestamp Tn will be wrote into
DM TLV. Otherwise, the DM TLV will contain an ingress sending
timestamp only. When the packet arrives at the egress node N3, a
Li & Chen Expires September 6, 2018 [Page 13]
Internet-Draft Passive PM for SRv6 NP March 2018
copied packet with its timestamp will be punted to CPU for further
processing.
6.2. Loss Measurement procedures
For measuring packet loss, there are two options. In both options,
LM-bit needs to be set. If there is a LM TLV in SRH, PMI will be
carried by LM TLV. Otherwise, the PMI will be carried by SIDs.
6.2.1. Using SIDs
If choosing the option of using SIDs to carry packet loss MI, the
SRH.Flag.LM-bit needs to be set, and LM TLV MUST NOT appear in SRH.
After updating IPv6 DA with A2::1, the ingress node N1 updates A2::1
with the current counter value and then forwards packet to N2
according to matched FIB entries. Assuming that the corresponding
counter value is C1, then the updated packet header becomes (B1,
A2::1) (A3::D10, A2::C1, SL=1) (CE-A, CE-B).
When node N2 receives the packet with DA A2::1 which is an End SID
originated by N2, node N2 will insert "Update SRH[SL][64:] with the
current counter value" after instruction of "update DA with SRH[SL]",
and then process End SID.
After updating IPv6 DA with SRH[0] A::D10, the current counter value
will be recorded at the last 64 bits of End SID A3::D10. Assuming
that the value of corresponding counter is C2, then the updated
packet header becomes (B1, A3::D10) (A3::C2, A2::C1, SL=0) (CE-A, CE-
B). According to the updated DA A3::D10, the packet will be
forwarded to N3.
When the egress node N3 receives the packet with header (B1, A3::D10)
(A3::C2, A2::C1, SL=0) (CE-A, CE-B), node N3 punts a copied packet
with its corresponding counter value to CPU for further processing
since the packet has reached the egress node. Then, N3 decapsulates
the outer header and forwards the inner packet to CE-B based on the
routes in tenant-10 IPv4 table since the DA is a local End.DT4 SID.
Measurement can be implemented by node or a remote controller. The
algorithm of packet loss measurement is the same as defined at
[RFC6374]. Per-hop packet loss or end-to-end packet loss can be
measured by data packets without additional OAM packets.
Li & Chen Expires September 6, 2018 [Page 14]
Internet-Draft Passive PM for SRv6 NP March 2018
6.2.2. Using LM TLV
If choosing the option of using LM TLV to carry packet loss MI, and
the SRH.Flag.LM-bit needs to be set, and a LM TLV needs to be
inserted in SRH with the flag set accordingly.
Using the LM TLV will not affect the processing of SIDs. But before
sending a data packet, the ingress node N1 should write the counter
value into LM TLV. When the middle node N2 receives a data packet,
it should inspect the existence of LM TLV. If there is a LM TLV in
SRH and the SRH.LM.I-flag is set, then a counter value Cn will be
wrote into LM TLV. Otherwise, the LM TLV will contain the counter
value at the ingress node only. When the packet arrives at the
egress node N3, a copied packet with its counter value will be punted
to CPU for further processing.
6.3. End.IOAM
In many scenarios, such as In-situ OAM, a copied packet with
corresponding metadata needs to be punted to CPU at a node in the
network. This document proposes a new SID function called End.IOAM
to implement it. This Function uses the reseved opcode which is TBA.
It can be inserted in any location of SIDs list to punt a copied data
packet at any node along the SRv6 path.
When N receives a packet destined to S and S is a local End.IOAM SID,
N does:
1.Punt a copied packet with metadata to CPU for further processing ;;Ref1
o Ref1: The corresponding metadata should be obtained according to
the IOAM data type. In this draft, IOAM data such as timestamp
can be indicated by SRH flags.
If the last SID is a End.IOAM SID, two copied packets will be punted
since the another packet will be punted as well by SL=0. The
solution of solving this problem will be futher discussed in a future
verison of this document.
7. IANA Considerations
TBA
8. Security Considerations
TBA
Li & Chen Expires September 6, 2018 [Page 15]
Internet-Draft Passive PM for SRv6 NP March 2018
9. Acknowledgements
TBA
10. References
10.1. Normative References
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
Camarillo, "SRv6 Network Programming", draft-filsfils-
spring-srv6-network-programming-03 (work in progress),
December 2017.
[]
Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
Field, B., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
Header (SRH)", draft-ietf-6man-segment-routing-header-08
(work in progress), January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References
[I-D.fioccola-spring-flow-label-alt-mark]
Fioccola, G., Velde, G., Cociglio, M., and P. Muley,
"Using the IPv6 Flow Label for Performance Measurement
with Alternate Marking Method in Segment Routing", draft-
fioccola-spring-flow-label-alt-mark-01 (work in progress),
October 2017.
[I-D.ietf-ippm-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate Marking method for passive and hybrid
performance monitoring", draft-ietf-ippm-alt-mark-14 (work
in progress), December 2017.
Li & Chen Expires September 6, 2018 [Page 16]
Internet-Draft Passive PM for SRv6 NP March 2018
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-02 (work in progress), March 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-12
(work in progress), February 2018.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
Authors' Addresses
Cheng Li
Huawei
Email: chengli13@huawei.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Li & Chen Expires September 6, 2018 [Page 17]