ForCES Working Group S. Blake Internet-Draft Z. Haraszti Expires: January 10, 2005 Modular Networks July 12, 2004 Some Possible Extensions of the Current LFB Model draft-blake-forces-attrib-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The ForCES Forwarding Element Model [Model] defines a model and schema for representing Logical Functional Block (LFB) classes and their operational and capability attributes. The operational attributes of LFB instances within a Forwarding Element (FE) are manipulated by the ForCES protocol [ForCES] to configure the operation of the FE. The model assumes that any particular LFB attribute is owned and accessed exclusively by a single LFB instance. While this is a simple and clean restriction, we observe that it imposes some complications when defining LFBs. This memo addresses Blake & Haraszti Expires January 10, 2005 [Page 1] Internet-Draft Possible LFB Model Extensions July 2004 these complications and proposes that the restriction be re-examined. 1. Introduction The ForCES Forwarding Element Model [Model] defines a model and XML schemas for representing Forwarding Elements (FEs) and the Logical Functional Block (LFB) classes that are used to model the FE's datapath. Attributes and capabilities of the FE such as LFB topology, LFB topology configurability, neighbor information, etc., can be represented by the FE schema. LFB operational and capability attributes such as flags, tables, and maximum ranges of other attributes, can be represented by the LFB class schema. LFB classes are modeled as flat entities (e.g., non-hierarchical, non-nested). The operational attributes of LFB instances are manipulated by the ForCES protocol [ForCES] to configure the operation of the FE (ignoring for the moment the possibility of reconfiguring the LFB topology, which is an FE attribute). [Model] defines a scheme wherein LFB attributes are defined exclusively per-LFB class. As a consequence, an attribute of a LFB instance (such as a table entry) is owned and accessed exclusively by a single LFB instance, and can be manipulated (e.g., read or written) by the protocol in messages addressed specifically to that LFB (or potentially to a subset of all LFBs of that class). The intent of [Model] is to define LFB classes such that each represents "a fine-grained, logically separable and well-defined packet processing operation in the datapath." As the authors have attempted to define a comprehensive family of LFBs, they have observed that this intent is occassionally in conflict with the restriction that LFB attributes are owned, accessed, and configured exclusively per-LFB instance. This memo gives a few examples of problems encountered while attempting to define a comprehensive set of LFB classes, and discusses some possible extensions of the LFB class model that would simplify the process of defining LFB classes. 2. LFB Class Examples The following three examples illustrate complications that were encountered when attempting to define LFB classes. 2.1 LPM Classifier and Next Hop LFBs Normal IP destination address-based forwarding is represented in [Model] by a sequence of two LFBs: a Classifier LFB supporting Longest Prefix Match (LPM) on the IP destination address (either IPv4 Blake & Haraszti Expires January 10, 2005 [Page 2] Internet-Draft Possible LFB Model Extensions July 2004 or IPv6), along with a Next Hop LFB, which resolves the next hop information associated with the best-matching prefix entry, potentially by selecting between multiple equal-cost paths. There is an additional function that is often performed by edge routers: network ingress filtering [RFC2827], which is used to confirm that a packet arrived on an expected interface, and hence the packet's source address is unlikely to have been spoofed. This function is often implemented by performing a forwarding search on the packet's source IP address S, and confirming that the packet's incoming interface is (one of) the path(s) that a packet with destination address S would be forwarded on. In detail, an LPM search in the forwarding prefix database is performed using S, and the (set of) associated next hop(s) is compared against the packet's incoming interface to determine whether the is a match. A natural LFB representation of this function would be a sequence of LPM classifier and Next Hop Comparison LFBs. The former would perform a search using the packet's source address. The latter would perform a comparison of the packet's incoming interface id (represented as metadata) against a set of one or more next hop attributes. This pair of LFBs would be separate from the LPM Classifier/ Next Hop LFB pair used for destination-address forwarding. A complication of this representation is that the two new LFBs require the exact same attribute configuration as the ones used for destination address-based forwarding. Since LFB attributes cannot be shared, the attributes for these LFBs must be configured separately, in sync with the configuration of the other pair. This introduces extra ForCES protocol exchanges which adds extra complexity to the CE software. It also introduces the opportunity to misconfigure the two pairs of LFBs, which might lead to indeterminate results, especially if the attributes are actually shared in the FE implementation (e.g., by a common memory database). An alternative, partially described in [Model], is to define the LPM Classifier and the Next Hop LFBs in such a way that they can handle both the destination and source address LPM searches (LPM Classifier) and the normal next hop match and next hop comparison functions (Next Hop). This introduces a loop in the LFB topology, along with additional inputs and outputs for each LFB. It also complicates the definition of the LFBs, which no longer perform fine-grained, logically separable functions. 2.2 ARP and L2 Address Resolution LFBs The ARP (Neighbor Discovery) function is occasionally offloaded to a FE. ARP is used to populate the L2 address resolution table for the router's interfaces (when static entries are not defined). [Model] Blake & Haraszti Expires January 10, 2005 [Page 3] Internet-Draft Possible LFB Model Extensions July 2004 defines a L2 Address Resolution LFB, which is used to determine the L2 destination address for an outgoing packet. This LFB owns the L2 address resolution table as a table of attributes. This is problematic, since an ARP LFB would need to configure this table, and the position of this LFB in the topology may not be adjacent to the L2 Address Resolution LFB. 2.3 Interface MIB counter handling The Interfaces Group MIB [RFC2863] defines a set of counters that are maintained on every IP (sub-)interface. Some of these counters (e.g., ifInUcastPkts/ifInMulticastPkts/ifInBroadcastPkts and ifInErrors) are exclusive (no packet may cause both of these to be incremented). To support this requirement, the relevant LFBs must be defined so that there is a common decision point to increment one or the other of these counters. This issue is partially handled in [Model] by defining an IP Interface LFB which contains all of the Interfaces Group MIB counters as attributes and includes all of the necessary IP header verification functions needed to determine whether a received packet is in error. Such an LFB would be quite complicated, especially considering all of the IP option (extension header) processing that may need to be performed to fully verify that a received packet is not in error. Ideally, the verification functions would be split into separate LFBs. However, the outcome of these functions is to update the interface counters, which are attributes of the IP Interface LFB as currently defined. From a ForCES model and protocol perspective, it is desirable to have a single LFB which hosts the complete set of interface counters (at least per-direction). 3. Problem Statement In reflecting on the previous examples (along with others), the authors determined that complexities occur due to lack of support in [Model] of one or more of the following features: 1. Efficient, bundled configuration of multiple LFBs 2. Attribute sharing between LFBs 3. Inter-LFB control The problems which might be solved by supported the listed features are inter-related, and could possibly be solved by a common extension to the model, or a small number of extensions. Note that there are work-arounds to each of the examples mentioned in Section 2, however, they are either inefficient or ugly. Blake & Haraszti Expires January 10, 2005 [Page 4] Internet-Draft Possible LFB Model Extensions July 2004 3.1 Bundled Configuration of LFBs There is a common paradox between the simultaneous goals of: o good functional separation between LFBs (e.g., high granularity), and o efficient, one-step configuration of a certain function, which begs for a single, complex LFB. In the absence of support for LFB attribute sharing, it may be necessary for the ForCES model and protocol to support the simultaneous configuration of attributes in multiple LFBs, to assure consistency, and to simplify the CE software utilizing the ForCES protocol. 3.2 Attribute Sharing Between LFBs There is another common paradox between the simultaneous goals of: o clean, logical LFB topology graph, which reflects the order of packet processing, promoting high-granularity LFBs, and o the need to share attributes between multiple forwarding functions, promoting low-granularity/higher-complexity LFBs. If a LFB could access attributes owned by and configured for another LFB, then this paradox could be resolved. Another alternative would be to define certain attributes as FE-level attributes, and allow multiple LFBs to access them, but this would potentially complicate the FE model. 3.3 Inter-LFB Control As shown in Section 2.2, one LFB may need to configure the attributes of another LFB (if they are not shared). This can be modeled by defining special control metadata that flows with packets between the affected LFBs, but this solution has the potential to be quite ugly. Another alternative would be to introduce inter-LFB control paths in the LFB topology, but this is a significant extension to the model. 4. Possible Model Extensions A solution to the issues illustrated above will likely require extending [Model]. Ideally, a single, simple extension to the model would be sufficient to address these issues (and potentially other issues that haven't been encountered yet). Any proposed extension should not significantly complicate the model nor the ForCES protocol definition or usage, and it should not Blake & Haraszti Expires January 10, 2005 [Page 5] Internet-Draft Possible LFB Model Extensions July 2004 complicate the definition of LFBs that do not pose any of these problems. Further, use of any proposed extension should be optional. Non-explicit solutions (e.g., those involving hidden relationships between LFBs that are not exposed by the model) are undesirable, since they impede interoperability between CEs and FEs, and potentially between FEs sourced from multiple vendors. The following proposed extensions may satisfy one or more of the three features listed in Section 3: o Dispatcher (proxy) LFB: a dispatcher LFB, not in the datapath topology, would be the configuration point for the protocol, and would directly configure two or more LFBs in the topology. Solves: Bundled configuration. o Protocol messages addressing multiple LFBs: ForCES protocol messages could be defined to simultaneously configure multiple LFBs (of different classes). Solves: Bundled configuration. o Nested LFBs: A LFB could be composed of multiple LFBs in an internal graph, each sharing attributes of the parent LFB. Solves: Bundled configuration, Shared attributes. o FE-level attributes, accessible to some or all LFBs in a FE: Some attributes accessed by LFBs could be defined as FE-level attributes. Solves: Shared attributes. o Resource "soft-links"/LFBs "exporting" certain attributes to other LFBs: Mechanisms in the model could be defined to allow LFB instances to export attributes, and allow other LFB instances to link to those attributes (e.g., ln -s in Unix). Solves: Shared attributes. o Decoupling nodes in the LFB topology from LFB instances: One LFB instance may show up in the topology as two or more nodes. Solves: Shared attributes, Inter-LFB control. o Configuration/control channels between LFBs: The model could be extended to support configuration/control channels between LFBs, which show up in the LFB topology. Solves: Bundled configuration, Shared attributes, Inter-LFB control. The proposed extensions listed above are not an exhaustive list. The authors encourage input from the ForCES working group to evaluate and extend this list. 5. Summary The ForCES model [Model] will likely need one or more extensions to address the problems discussed in this memo. These extensions should be backwards compatible additions, with little or no effect on mature LFB definitions (few of these exist at the moment, however). Sharing of attributes between LFBs should be optional in many cases, but it must be explicitly visible to the CE; otherwise, the configuration Blake & Haraszti Expires January 10, 2005 [Page 6] Internet-Draft Possible LFB Model Extensions July 2004 model of the FE is potentially indeterminate. Further analysis of these problems and the proposed solutions is needed. 6. Acknowledgements The authors would like to thank Anurag Bhargava, Ho-yen Chang, Arthur Davis, Peter Denz, Reda Haddad, and Stephen Nadas, for many hours of brainstorming with the authors, which revealed the issues presented in this memo. 7 References [Model] Yang, L., Halpern, J., Gopal, R., Dekok, A., Haraszti, Z., Blake, S. and E. Deleganes, "ForCES Forwarding Element Functional Model", draft-ietf-forces-model-02 (work in progress), February 2004. [ForCES] Doria, A., Dong, L., Gopal, R., Haas, R., Salim, J., Khosravi, H. and W. Wang, "ForCES Protocol Specification", draft-doria-forces-protocol-00 (work in progress), June 2004. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Authors' Addresses Steven Blake Modular Networks First Flight Venture Center 2 Davis Drive PO Box 12076 Research Triangle Park, NC 27709 USA Phone: +1 919 765-0027 x2016 EMail: slblake@modularnet.com Blake & Haraszti Expires January 10, 2005 [Page 7] Internet-Draft Possible LFB Model Extensions July 2004 Zsolt Haraszti Modular Networks First Flight Venture Center 2 Davis Drive PO Box 12076 Research Triangle Park, NC 27709 USA Phone: +1 919 765-0027 x2017 EMail: zsolt@modularnet.com Blake & Haraszti Expires January 10, 2005 [Page 8] Internet-Draft Possible LFB Model Extensions July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Blake & Haraszti Expires January 10, 2005 [Page 9]