idnits 2.17.1
draft-ietf-sfc-nsh-tlv-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 :
----------------------------------------------------------------------------
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 97: '... Context Headers MAY be added, immedia...'
RFC 2119 keyword, line 101: '... Context Headers MUST be of an integer...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 29, 2018) is 2272 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref. 'NSH'
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Quinn
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Standards Track U. Elzur
5 Expires: August 2, 2018 Intel
6 S. Majee
7 F5
8 January 29, 2018
10 Network Service Header TLVs
11 draft-ietf-sfc-nsh-tlv-00.txt
13 Abstract
15 This draft describes Network Service Header (NSH) MD-Type 2 metadata
16 TLVs that can be used within a service function path.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on August 2, 2018.
35 Copyright Notice
37 Copyright (c) 2018 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. NSH Type 2 Format . . . . . . . . . . . . . . . . . . . . . . 2
54 3. NSH Type 2 TLVs . . . . . . . . . . . . . . . . . . . . . . . 3
55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
56 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
59 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
60 7.2. Informative References . . . . . . . . . . . . . . . . . 7
61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
63 1. Introduction
65 Network Service Header [NSH] is the SFC encapsulation protocol used
66 to create Service Function Chains. As such, NSH provides two key
67 elements:
69 1. Service Function Path identification
71 2. Metadata
73 NSH further defines two metadata formats (MD Types): 1 and 2. MD
74 Type 1 defines fixed length, 16 byte metadata, whereas MD Type 2
75 defines a variable-length TLV format for metadata. This draft
76 defines some common TLVs for use with NSH MD Type 2.
78 This draft does not address metadata usage, updating/chaining of
79 metadata or other SFP functions. Those topics are described in NSH.
81 2. NSH Type 2 Format
83 A NSH is composed of a 4-byte Base Header, a 4-byte Service Path
84 Header and Context Headers. The Base Header identifies the MD-Type
85 in use:
87 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
88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
89 |Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Protocol |
90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
92 Figure 1: NSH Base Header
94 Please refer to NSH [NSH] for a detailed header description.
96 When the base header specifies MD Type= 0x2, zero or more Variable
97 Length Context Headers MAY be added, immediately following the
98 Service Path Header. Therefore, Length = 0x2, indicates that only
99 the Base Header followed by the Service Path Header are present. The
100 number, indicated in the length field, of optional Variable Length
101 Context Headers MUST be of an integer indicating length in 4-bytes
102 words Figure 3 below depicts the format the context header.
104 0 1 2 3
105 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
106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
107 | TLV Class |C| Type |R|R|R| Len |
108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
109 | Variable Metadata |
110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
112 Figure 2: NSH TLV Format
114 3. NSH Type 2 TLVs
116 As per NSH, TLV Class 0-7 are reserved for standards use. In this
117 draft we use TLV Class 0 for the following Types:
119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
120 | TLV Class = 0x0 |C| Type |R|R|R| Len |
121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
122 | Variable Metadata |
123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
125 Figure 3: NSH TLV Class=0x0
127 1. Forwarding Context
129 This TLV carries network-centric forwarding context, used for
130 segregation and forwarding scope. Forwarding context can take
131 several forms depending on the network environment. Commonly
132 used data includes VXLAN/VXLAN- GPE VNID, VRF identification or
133 VLAN.
135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
136 | TLV Class = 0x0 |C| Type=0x1 |R|R|R| L=0x2 |
137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
138 |CT (4)| Reserved |
139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
140 | Tentant ID |
141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
143 Context Type (CT), 4 bits:
144 0x0: 24 bit VXLAN/LISP virtual network identifier (VNI)
145 0x1: 32 bit MPLS VPN label
146 0x2: VLAN
148 Figure 4: Forwarding Context
150 2. Tenant
152 Tenant identification is often used for segregation within a
153 multi-tenant environment. Orchestration system generated tenant
154 IDs are an example of such data.
156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
157 | TLV Class = 0x0 |C| Type=0x4 |R|R|R| L=0x3 |
158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
159 |TT (4)| Reserved |
160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
161 | Tenant ID |
162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
163 | Tenant ID |
164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
166 Tenant Type (TT), 4 bits:
167 0x0: 32 bit
168 0x1: 64 bit
170 Figure 5: Tenant Identifier
172 3. Content Type
174 Provides explicit information about the content being carried,
175 for example, type of video or content value for billing purposes
177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
178 | TLV Class = 0x0 |C| Type=0x6 |R|R|R| L=0x1 |
179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
180 | Content Type |
181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
183 Figure 6: Content Type
185 4. Ingress Network Information
187 This data identifies ingress network node, and, if required,
188 ingress interface.
190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
191 | TLV Class = 0x0 |C| Type=0x7 |R|R|R| L=0x2 |
192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
193 | Node ID |
194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
195 | Source Interface/Port |
196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
198 Figure 7: Ingress Network Info
200 5. Flow ID
202 Flow ID provides a representation of flow. Akin, but not
203 identical to the usage described in [RFC6437]
205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
206 | TLV Class = 0x0 |C| Type=0x8 |R|R|R| L=0x1 |
207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
208 | Flow ID |
209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
211 Figure 8: Flow ID
213 6. Source and/or Destination Groups
215 Intent-based systems can use this data to express the logical
216 grouping of source and/or destination objects.
217 [GROUPBASEDPOLICY] and [GROUPPOLICY] provide examples of such a
218 system.
220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
221 | TLV Class = 0x0 |C| Type=0x9 |R|R|R| L=0x3 |
222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
223 |GT(4) | Reserved |
224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
225 | Source Group |
226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
227 | Dest Group |
228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230 Group type (4):
231 0x1: Group Based Policy (GBP) end point group (EPG)
233 Figure 9: End Point Group
235 7. Universal Resource Identifier (URI)
237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
238 | TLV Class = 0x0 |C| Type=0xA |R|R|R| L=var |
239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
240 |UT(4) | URI |
241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
242 ~ URI ~
243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
245 URI type (4):
246 0x1: URI in standard string format as defined in RFC 3986
247 0x2: URI represented in a compacted hash format
249 Figure 10: URI
251 8. Policy Identifier (POLICY_ID)
253 Policy is often referred by a system generated identifier which
254 is then used by the devices to lookup the content of the policy
255 locally. For example this identifier could be an index to an
256 array, a lookup key, a database Id. The identifier allows
257 enforcement agents or services to lookup up the content of their
258 part of the policy quite efficiently.
260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
261 | TLV Class = 0x0 |C| Type=0xB |R|R|R| L=0x2 |
262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
263 | POLICY_ID |
264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
265 ~ POLICY_ID ~
266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268 Figure 11: POLICY_ID
270 4. Security Considerations
272 NSH describes the requisite security considerations for protecting
273 NSH metadata.
275 5. Acknowledgments
277 The authors would like to thank Behcet Sarikaya, Dirk von Hugo and
278 Mohamed Boucadair for their work regarding usage of subscriber and
279 host information TLVs.
281 6. IANA Considerations
283 IANA is requested to create a new "Network Service Header (NSH) TLV
284 Type" registry. TLV types 0-127 are specified in this document. New
285 values are assigned via Standards Action [RFC5226].
287 7. References
289 7.1. Normative References
291 [NSH] Quinn, P., Ed. and U. Elzur, Ed., "Network Service
292 Header", 2016, .
295 7.2. Informative References
297 [GROUPBASEDPOLICY]
298 OpenStack, "Group Based Policy", 2014,
299 .
301 [GROUPPOLICY]
302 OpenDaylight, "Group Policy", 2014,
303 .
305 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
306 IANA Considerations Section in RFCs", RFC 5226,
307 DOI 10.17487/RFC5226, May 2008, .
310 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
311 "IPv6 Flow Label Specification", RFC 6437,
312 DOI 10.17487/RFC6437, November 2011, .
315 Authors' Addresses
317 Paul Quinn
318 Cisco Systems, Inc.
320 Email: paulq@cisco.com
322 Uri Elzur
323 Intel
325 Email: uri.elzur@intel.com
327 Sumandra Majee
328 F5
330 Email: S.Majee@F5.com