idnits 2.17.1 draft-guichard-sfc-metadata-header-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 date (September 27, 2013) is 3865 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Guichard 3 Internet-Draft S. Spraggs 4 Intended status: Standards Track C. Pignataro, Ed. 5 Expires: March 31, 2014 S. Bryant 6 Cisco 7 September 27, 2013 9 Common Metadata Header Format for IP/MPLS Networks 10 draft-guichard-sfc-metadata-header-00 12 Abstract 14 This document defines the common format for the metadata header used 15 to carry metadata in IPv4, IPv6, and MPLS packets. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 31, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Metadata Component Structure . . . . . . . . . . . . . . . . . 3 60 3. Metadata Channel Header Format . . . . . . . . . . . . . . . . 4 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 This document defines a common header format that is used in IPv4, 73 IPv6 and MPLS packets to carry metadata in addition to the payload. 74 The format of specific metadata types and how the metadata is used is 75 outside the scope of this document. Anticipated uses of metadata 76 include instrumentation of user data frames and service chaining. 78 Mechanisms for identification of the presence of metadata within an 79 IPv4, IPv6, or MPLS packet are addressed in separate documents 80 [I-D.guichard-mpls-metadata]. 82 1.1. Terminology 84 ACH Associated Channel Header 86 MCH Metadata Channel Header 88 MD Metadata 90 2. Metadata Component Structure 92 The structure of the metadata component is common for IPv4, IPv6, and 93 MPLS encapsulations. It is comprised of a Header and a channel 94 carrying Metadata, and is followed by the original packet payload. 95 Figure 1 shows the complete structure: 97 0 1 2 3 98 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 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Metadata Channel Header (MCH) | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Metadata Channel (variable) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Original Payload | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 Figure 1: Metadata Component Structure 109 The meanings of the metadata components are: 111 o Metadata Channel Header (MCH): common header used for IPv4, IPv6, 112 and MPLS packets to indicate the type and structure of the 113 metadata carried within the packet. 115 o Metadata Channel: the actual metadata. The length and format of 116 the metadata channel is outside the scope of this document and 117 will vary depending upon the "Metadata Channel Type" specified in 118 the MCH. It is anticipated that there will be a number of 119 instrumentation channels, as well as channels for functionality. 121 o Original Payload: beneath the metadata will be the original 122 packet payload. This could be L3, L2 or MPLS payload. 124 3. Metadata Channel Header Format 126 The Metadata Channel Header (MCH) is similar in structure to the 127 Associated Channel Header (ACH) as defined in [RFC5586]. The type 128 and format of the actual metadata is defined in other documents. 130 The proposed format of the MCH is as depicted in Figure 2: 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |0 0 0 0|Version| Protocol | Metadata Channel Type | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 Figure 2: Metadata Channel Header Format 140 The meanings of the fields in the MCH are: 142 o First Nibble: it is set to 0000b to indicate a Metadata Channel 143 associated with IPv4, IPv6, or MPLS. 145 o Version: version number of the metadata channel. This 146 specification defines a value of 0. 148 o Protocol: Where the network layer is MPLS this MUST be set to a 149 value of 0 and ignored on reception. Where the network layer is 150 IPv4 [RFC0791] this carries the protocol number that identifies 151 the protocol that follows the metadata, i.e. it contains the 152 protocol number that would have been in the IP header if the 153 metadata had not been inserted. Similarly if the network layer is 154 IPv6 [RFC2460] this is the final next-header value that would have 155 been present if the metadata had not been inserted. 157 o Metadata Channel Type: The Metadata Channel Type is defined in 158 the IANA Metadata Channel Type registry Section 4. 160 4. IANA Considerations 162 This document request IANA to create and maintain the "Metadata 163 Channel Type" registry. Registry entries are assigned by using the 164 "IETF Review" policy defined in [RFC5226]. 166 IANA are requested to initally mark the registry as follows: 167 Value Description 168 -----------------+------------------------------- 169 0x0000 Reserved 170 0x0001 - 0x7FF7 Unassigned 171 0x7ff8 - 0x7FF7 Reserved for Experimental Use 172 0x8000 - 0xFFFF Unassigned 174 5. Security Considerations 176 The security considerations associated with the addition of metadata 177 to packets are discussed in the network layer specific documents 178 [I-D.guichard-mpls-metadata]. The security risks associated with 179 each metadata type that is defined MUST be documented as part of the 180 definition. 182 6. Contributing Authors 184 o Clarence Filsfils 186 o Dan Frost 188 7. Acknowledgments 190 The authors would like to thank Giles Heron and Tom Nadeau for their 191 review and useful comments. 193 8. References 195 8.1. Normative References 197 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 198 September 1981. 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, March 1997. 203 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 204 (IPv6) Specification", RFC 2460, December 1998. 206 8.2. Informative References 208 [I-D.guichard-mpls-metadata] 209 Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant, 210 "Carrying Metadata in MPLS Networks", 211 draft-guichard-mpls-metadata-00 (work in progress), 212 June 2013. 214 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 215 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 216 May 2008. 218 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 219 Associated Channel", RFC 5586, June 2009. 221 Authors' Addresses 223 Jim Guichard 224 Cisco Systems, Inc. 226 Email: jguichar@cisco.com 228 Simon Spraggs 229 Cisco Systems, Inc. 230 10 New Square Park 231 Bedfont Lakes, Feltham TW14 8HA 232 United Kingdom 234 Email: sspraggs@cisco.com 236 Carlos Pignataro (editor) 237 Cisco Systems, Inc. 238 7200-12 Kit Creek Road 239 Research Triangle Park, NC 27709 240 US 242 Email: cpignata@cisco.com 243 Stewart Bryant 244 Cisco Systems, Inc. 245 10 New Square Park 246 Bedfont Lakes, Feltham TW14 8HA 247 United Kingdom 249 Email: stbryant@cisco.com