idnits 2.17.1 draft-dekok-forces-metadata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 212, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-forces-requirements (ref. '1') == Outdated reference: A later version (-16) exists of draft-ietf-forces-model-01 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. DeKok 3 Expiration: March 2003 IDT, Inc. 4 Working Group: Forces October, 2003 6 A Discussion of Metadata in ForCES 7 draft-dekok-forces-metadata-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes a model for discussing metadata in ForCES. 31 It defines multiple kinds of metadata, and shows which ones are in 32 scope for ForCES, and which ones are out of scope for ForCES. It 33 further defines a vocabulary for discussing metadata, which should 34 help to avoid much of the historical confusion and disagreement 35 surrounding discussions of metadata. 37 Table of Contents 39 Abstract...........................................................1 40 1. Introduction ...................................................2 41 2. An exposition of metadata ......................................2 42 2.1 Internal versus External Metadata ...........................2 43 2.2 Implicit versus Explicit Metadata ...........................3 44 3. Further Exposition .............................................3 45 3.1 More detailed examples ......................................3 46 3.2 The concept of "scale" as it impacts metadata ...............4 47 4. Implication for ForCES .........................................4 48 5. Security Considerations ........................................5 49 6. Intellectual Property Right ....................................5 50 7. Normative References ...........................................5 51 8. Informative References .........................................5 52 9. Acknowledgments ................................................5 53 10. Authors' Addresses ............................................6 55 1. Introduction 57 Metadata has historically been understood to mean "data about data". 58 While this definition is better than nothing, it has contributed 59 significantly to misunderstanding and miscommunication, when disparate 60 parties attempt to discuss the topic. Our goal in this document is to 61 give a more detailed definition of metadata, to show where different 62 kinds of metadata occur in network devices, and to explain those 63 differences via specific examples. 65 2. An Exposition of Metadata 67 Our presentation of metadata divides it by two orthogonal axes: Internal 68 versus External, and Implicit versus Explicit. 70 2.1 Internal versus External Metadata 72 We define Internal metadata as data which is produced and consumed 73 entirely within a particular context (usually network device or chip). 75 For example, an Ethernet MAC may have an internal timer associated with 76 a packet it is trying to transmit. If a collision is detected during 77 transmission, the MAC performs an exponential back-off, and attempts to 78 re-transmit the packet. The timer associated with that exponential 79 back-off is internal to the MAC, and usually cannot be seen by any 80 driver software. Nevertheless, that timing data is in the MAC, and is 81 associated with the current packet. We can therefore describe that 82 timing data as metadata about the current packet. 84 We define External metadata as data which is visible outside of a 85 particular context (usually network device or chip). 87 For example, a chip implementing an 8-port switch fabric may need to be 88 told the output port to which an input packet will be redirected, if it 89 does not make that decision itself. That information may be supplied 90 via in-band data, such as a series of bits which precede the packet, or 91 it may be supplied via other methods. In either case, the information 92 which tells the switch fabric chip where to redirect the packet may be 93 described as metadata, which is external to the switch fabric chip. 95 2.2 Implicit versus Explicit Metadata 97 We define Implicit metadata as data which may be determined implicitely 98 from context. 100 For example, an Ethernet MAC is never told that the packets it receives 101 are in Ethernet format. That information is determined implicitly by 102 the fact that the physical form factor of Ethernet cabling ensures 103 (generally) that only transmitters of Ethernet packets are connected to 104 receivers of Ethernet packets. The receivers, therefore, are never told 105 explicitly that the packets are in Ethernet format. Instead, they 106 proceed under the assumption that the packets are Ethernet. 108 We define Explicit metadata as data which is given as information in 109 addition to the packet data. 111 For example, a chip implementing an 8-port switch fabric may be given 112 explicit information as to the output port to which an input packet will 113 be redirected. That information often cannot be determined implicitly 114 from context, but must be explicitly supplied by something external to 115 the switch fabric chip. 117 3. Further exposition. 119 The exposition of the axes used to describe metadata in Section 2 is 120 admittedly somewhat naive. This section gives more detailed 121 examples, and shows how the concept of "scale" impacts metadata. 123 3.1 More detailed examples 125 TCP packets are carried within IP packets, and the IP packet contains 126 a "protocol" field, with an explicit value of "6", for TCP. That 127 protocol field can be viewed from the perspective of the TCP packet 128 as Explicit, External metadata. In contrast, the format of the TCP 129 packet is implicitely defined, and is never sent over the wire. 130 Therefore, the TCP packet format can be viewed as Implicit, External 131 metadata. 133 IP MPLS can be viewed as associating 32 bits of Explicit, External 134 metadata with an IP packet. That metadata informs MPLS-aware devices 135 as to how the IP packet should be forwarded. The use of that 136 metadata allows MPLS-aware devices to perform that forwarding without 137 examining or modifying the IP packet. 139 More examples should be inserted here. 141 3.2 The concept of "scale" as it impacts metadata 143 The ForCES model document[2] describes how a network device may be 144 modelled via multiple Function Elements (FE's), each of which may be 145 modelled via multiple Logical Function Blocks (LFB's.) We now 146 discuss how the view of metadata changes at each level of that model. 148 The metadata exchanged between devices at one level of the model may 149 be viewed as External, Explicit metadata at that level. For example, 150 the metadata distributed between LFB's may include information such 151 as classification result, which may be represented as a sequence of 152 bits prefixing a packet. 154 At a higher level, however, the lower-level metadata may not be 155 visible. For example, an IPv4 forwarder may be represented as a set 156 of LFB's which exchange packets and metadata. At the FE level, the 157 metadata inside of the IPv4 forwarder may not be visible. The other 158 FE's will simply see a packet entering the device, and some time 159 later, a modified packet exiting the device. 161 The discussion of scale may be repeated until it encompasses the 162 Internet. Sets of LFB's form FE's, sets of FE's form network 163 devices, sets of network devices form networks, and sets of networks 164 form the Internet. At each level of scale, we can characterize 165 metadata as in Section 2, even though that same metadata may have a 166 different characterization at another scale. 168 This multiple interpretation of metadata becomes even more difficult 169 when we realize that different vendors have implementations which may 170 exist at multiple scales, or at disparate scales. For example, one 171 vendor may choose to implement an IPv4 forwarder in a monolithic 172 chip, while another implements an IPv4 forwarder through a set of 173 distinct chips. Both implementations must be controllable and 174 addressable through ForCES, which is a difficult proposition to 175 satisfy in general. 177 4. Implications for ForCES. 179 The discussion of metadata within the context of ForCES has 180 historically been contentious. We hope that this exposition of 181 metadata helps to decrease the confusion surrounding metadata, by 182 supplying a clear vocabulary which may be used to discuss the issue. 184 Further, we can use the preceding characterization of metadata to 185 narrow the scope of using metadata within the context of ForCES. 187 Specifically, Internal metadata should be described as outside of the 188 scope of ForCES. Vendors of network devices should be free to choose 189 any manner of implementing or representing metadata within their 190 devices. Any attempt by ForCES to standardize the representation or 191 use of Internal metadata would be an unwarranted burden on vendors. 193 In contrast, as one of the goals of ForCES is to facilitate inter- 194 vendor communication, External metadata is within the scope of 195 ForCES. The group should create definitions of, and standards for, 196 External metadata which permit different vendor implementations of 197 devices to communicate metadata. 199 That metadata may be Implicit (inputs to LFB 'X' are assumed to be 200 outputs from LFB 'Y'), and Explicit (this packet is to go out port 201 "4"). 203 We hope that this discussion of metadata terminology, scope, and 204 scale, helps in facilitating communication among members of ForCES. 206 5. Security Considerations 208 There are no security considerations associated with this document. 210 6. Normative References 212 [1] Khosravi, H. et al., "Requirements for Separation of IP Control 213 and Forwarding", work in progress, draft-ietf-forces- 214 requirements-10.txt, Intel Labs, July 2003. 216 7. Informative References 218 [2] Yang, Lily et. al., "ForCES Forwarding Element Model", work in 219 progress, draft-ietf-forces-model-01.txt, Intel Labs, October 2003. 221 8. Intellectual Property Right 223 The authors are not aware of any intellectual property right issues 224 pertaining to this document. 226 9. Acknowledgements 228 The authors would also like to thank the following individuals for 229 their valuable technical input: David Maxwell, Michael Richardson, 230 and Wojtek Fraczak. 232 10. Authors' Address 234 Alan DeKok 235 IDT Inc. 236 1575 Carling Ave. 237 Ottawa, ON 238 Canada 239 K1Z 7M3 240 Email: alan.dekok@idt.com