idnits 2.17.1
draft-dang-ippm-multiple-path-measurement-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (March 4, 2019) is 1873 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 279, but no explicit
reference was found in the text
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. Dang, Ed.
3 Internet-Draft Huawei
4 Intended status: Informational March 4, 2019
5 Expires: September 5, 2019
7 A Multi-Path Concurrent Measurement Protocol for IPPM
8 draft-dang-ippm-multiple-path-measurement-00
10 Abstract
12 This test method can test multi-paths concurrently between two edge
13 nodes. This document details Multi-Path Concurrent Measurement
14 Protocol (MPCMP).
16 Status of This Memo
18 This Internet-Draft is submitted in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF). Note that other groups may also distribute
23 working documents as Internet-Drafts. The list of current Internet-
24 Drafts is at https://datatracker.ietf.org/drafts/current/.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 This Internet-Draft will expire on September 5, 2019.
33 Copyright Notice
35 Copyright (c) 2019 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (https://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
52 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 2
53 2. Overview of Multi-Path Concurrent Measurement Protocol . . . 3
54 3. MPCMP-Test Packet Format and Content . . . . . . . . . . . . 3
55 4. Expansion based on various measurement methods . . . . . . . 6
56 4.1. IOAM . . . . . . . . . . . . . . . . . . . . . . . . . . 6
57 5. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 6
58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
61 9. Normative References . . . . . . . . . . . . . . . . . . . . 6
62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
64 1. Introduction
66 In load-balancing scenario, there are multiple paths adopted between
67 two edge nodes. The traffic from the Scr node to the Dst node is
68 required to be steered into to the specific path/paths basing on the
69 SLA information of each path. In the traditional method, the paths
70 are measured separately. If you want to ensure that the data
71 obtained by the test is available and accurate, then the test start
72 and end points of this set of Paths must be consistent.
74 The Multi-Path Concurrent Measurement Protocol (MPCMP) is required,
75 which can be used bi-directionally to concurrently measure multi-
76 paths metrics between two network elements. At the same time, this
77 method also saves the number of test messages and reduces the load on
78 the network.
80 1.1. Requirements Language
82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
84 document are to be interpreted as described in RFC 2119.
86 1.2. Terminology & Abbreviations
88 o Mutiple Paths
90 * There are multiple paths between two nodes in the network.
91 These paths may be equal-cost multi-path (ECMP) mode or
92 unequal-cost multiple (UCMP) mode. In a real network, they
93 might be one [draft-ietf-spring-segment-routing-policy] or
94 [RFC7348] tunnel.
96 o Concurrent
98 * In order to ensure comparability between multiple paths, the
99 test start point and the test end point are required to be
100 synchronized.
102 2. Overview of Multi-Path Concurrent Measurement Protocol
104 The Multi-Path Concurrent Measurement Protocol (MPCMP) is an open
105 protocol for measurement of multi-paths metrics.
107 MPCMP can be embedded into a variety of transports such as NSH,
108 Segment Routing, VxLAN, native IPv6 (via extension header), or IPv4.
110 3. MPCMP-Test Packet Format and Content
112 This section defines path header and associated data types required
113 for MPCMP.
115 0 1 2 3
116 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
117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
118 | Session ID |
119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
120 | Path ID | Path-E2E-Type |
121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
122 | Flags | Transaction ID |
123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
125 Figure 1: MPCMP Path header
127 o Session ID: A set of load sharing paths
129 o Path ID: One path of the session.
131 o Path-E2E-Type: A 16-bit identifier which Indicates whether the
132 packet type is a send message or a request message.
134 o Flags: 8-bit field. Identify the query or response type.
135 Following flags are defined:
137 * Bit 0 Identify the query type
139 * Bit 1 Identify the response type
141 * Reserved
143 o Transaction ID: 16-bit identifier of one measurement transaction.
144 The sender and receiver to identify measurement transactions based
145 on Transaction ID.
147 When a measurement is for a set of paths, each query message is made
148 for each path, but only one unified response message replies.
149 Therefore, the message format is defined as follows.
151 The measurement packet format of a path is as follows.
153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
154 | |
155 | E2E PathN Option Header |
156 | |
157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
158 | |
159 | PathN Edge-to-Edge Option Data |
160 | |
161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
163 Figure 2: Query message
165 The field of PathN Edge-to-Edge Option Data can refer to Edge-to-Edge
166 Option Data of [draft-ietf-ippm-ioam-data-04].
168 The response type message format is as follows. It suppose there are
169 N paths between two points.
171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
172 | |
173 | E2E Path1 Option Header |
174 | |
175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
176 | |
177 | Path1 Edge-to-Edge Option Data |
178 | |
179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
180 ~ ... ~
181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
182 | |
183 | E2E PathN-1 Option Header |
184 | |
185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
186 | |
187 | PathN-1 Edge-to-Edge Option Data |
188 | |
189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
190 | |
191 | E2E PathN Option Header |
192 | |
193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
194 | |
195 | PathN Edge-to-Edge Option Data |
196 | |
197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
199 Figure 3: Response message
201 o Long-term measurement
203 * The receiver can wait until it receives all measurement
204 requests of a set of path and then responds.
206 o Short-term measurement
208 * The Sender can query once t.
210 * The receiver can reply once t.
212 The overall solution needs to consider two methods of long-period
213 measurement and short-period measurement.
215 4. Expansion based on various measurement methods
217 The measurement message format defined by this document can be
218 extended based on various measurement methods.
220 4.1. IOAM
222 A new type is added in IOAM-E2E-Type of IOAM Edge-to-Edge Option
223 header[draft-ietf-ippm-ioam-data-04-section4.4] as follow.
225 o Bit 4: Multiple paths measurement.
227 This bit is set by the headend node if Multi-Path Concurrent
228 Measurement is activated.
230 A common registry is maintained for IOAM-Types, see Section 6.
232 5. Data Export
234 MPCMP nodes collect information for packets traversing a domain that
235 supports MPCMP. MPCMP process the information further and export the
236 information using e.g., IPFIX. Raw data export of IOAM data using
237 IPFIX is discussed in [draft-spiegel-ippm-ioam-rawexport-00].
239 6. IANA Considerations
241 This document requests the following IANA Actions.
243 IOAM E2E Type Registry:
245 Bit 4 Multiple ways measurement
247 7. Security Considerations
249 The Proof of Transit option (Section Section 4.3 In-situ OAM
250 [draft-ietf-ippm-ioam-data-04-section4.4]) is used for verifying the
251 path of data packets.
253 8. Acknowledgements
255 TBD
257 9. Normative References
259 [draft-ietf-ippm-ioam-data-04]
260 "A Variety of Transports",
261 .
264 [draft-ietf-ippm-ioam-data-04-section4.4]
265 "IOAM Edge-to-Edge Option",
266 .
269 [draft-ietf-spring-segment-routing-policy]
270 "Segment Routing Policy Architecture",
271 .
274 [draft-spiegel-ippm-ioam-rawexport-00]
275 "In-situ OAM raw data export with IPFIX",
276 .
279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
280 Requirement Levels", BCP 14, RFC 2119,
281 DOI 10.17487/RFC2119, March 1997,
282 .
284 [RFC7348] "Virtual eXtensible Local Area Network (VXLAN)",
285 .
287 Author's Address
289 Joanna Dang (editor)
290 Huawei
291 Beijing
292 China
294 Email: dangjuanna@huawei.com